Note by Damian Collins MP, Chair of the DCMS Committee 


Summary of key issues from the Six4Three files 


1. White Lists 

Facebook have clearly entered into whitelisting agreements with certain companies, which 
meant that after the platform changes in 2014/15 they maintained full access to friends 
data. It is not clear that there was any user consent for this, nor how Facebook decided 
which companies should be whitelisted or not. 

2. Value of friends data 

It is clear that increasing revenues from major app developers was one of the key drivers 
behind the Platform 3.0 changes at Facebook. The idea of linking access to friends data to 
the financial value of the developers relationship with Facebook is a recurring feature of 
the documents. 

3. Reciprocity 

Data reciprocity between Facebook and app developers was a central feature in the 
discussions about the launch of Platform 3.0. 

4. Android 

Facebook knew that the changes to its policies on the Android mobile phone system, 
which enabled the Facebook app to collect a record of calls and texts sent by the user 
would be controversial. To mitigate any bad PR, Facebook planned to make it as hard of 
possible for users to know that this was one of the underlying features of the upgrade of 
their app. 

5. Onavo 

Facebook used Onavo to conduct global surveys of the usage of mobile apps by customers, 
and apparently without their knowledge. They used this data to assess not just how many 
people had downloaded apps, but how often they used them. This knowledge helped 
them to decide which companies to acquire, and which to treat as a threat. 

6. Targeting competitor Apps 

The files show evidence of Facebook taking aggressive positions against apps, with the 
consequence that denying them access to data led to the failure of that business 



1. White Lists 


In the Six4Three documents, exhibits 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 94 and 95 include 
discussions on whitelisting businesses. The following are of note: 

Exhibit 84 - whitelisting of Badoo [dating appl 

Email from Badoo to Konstantinos Papamiltidas, Director of Platform Partnerships at 
Facebook, 16 September 2014: 

'We have been compelled to write to you to explain the hugely detrimental effect that 
removing friend permissions will cause to our hugely popular (and profitable) applications 
Badoo and Hot or Not. 

'The friends data we receive from users is integral to our product (and indeed a key reason 
for building Facebook verification into our apps).' 


Email from Konstantinos Papamiltidas to Badoo, 23 January 2015 

'We have now approval from our internal stakeholders to move ahead with a new API - 
working name Hashed Anon All Friends API. The new API as well as the relevant docs will be 
ready next week. 

'How would this API work...For each of the FB logged in users, the API will return: 

FBIDs: App friends that logged in before your migration to V2: 

App Scoped IDs: App friends that logged in after your migration to V2: 

Annonymous one-way hashed IDs: Non-app friends 

The API will hopefully let you understand some of the structure of the graph in order to 
determine which non-app friends to recommend to a given user.' 

Email 5 February 2015 

Konstantinos Papamiltidas - 'We have whitelisted Badoo App, HotorNot and Bumble for the 
Hashed Friends API that was shipped late last night.' 

Email - 6 February 2015 

Konstantinos Papamiltidas to Badoo 

'Badoo APP ID has definitely been whitelisted...According to out logs you have already made 
100 calls against this API.' 


Exhibit 87 - whitelisting of Lyft [taxi appl 


Email from Konstantinos Papamiltidas to Lyft, 30 March 2015 

'As far as I can tell, the App ID below has been whitelisted for All Mutual Friends access.' 


Exhibit 91 - whitelisting of AirBnB 

Email Konstantinos Papamiltidas to AirBnB, 18 March 2015 

'As promised, please find attached the docs for Hashed Friends API that can be used for 
social ranking. Let us know if this would be of interest to you, as we will need to sign an 
agreement that would allow you access to this API.' 


Exhibit 92 - whitelisting of Netflix 

Email 17 February 2015 between Netflix and Chris Barbour and Konstantinos Papamiltidas 
at Facebook 

Netflix wrote on 13 February 

'We will be whitelisted for getting all friends, not just connected friends' 


Exhibit 80 - discussion about the whitelisting process 

Email from Simon Cross [FB - Product Partnerships] to Konstantinos Papamiltidas [FB], Ime 
Archibong [FB] and Jackie Chang [FB] 

5 September 2013 12.33pm 

'I'd say for now just list out the capabilities/Gks/Sitevars we want to audit...We need to 
build collective experience on how to review the access that's been granted, and how to 
make decisions about keep/kill/contract. 

'This review cycle should include whats currently in Capabilities, as well as whitelists 
administered via Gks and Sitevars. I don't want to have to go through this exercise ever 
again. For example, we should appraise what Netflix (for example) has across all these three 
whitelisting mechanisms in one go.' 


2. Value of friends data 


Exhibit 83 - discussion of Royal Bank of Canada neko spend alongside whether they should 
be whitelisted 



Email from Sachin Monga at Facebook to Jackie Chang at Facebook, 10.38am on 20 August 
2013 regarding the impact of the platform changes on Royal Bank of Canada 

'Without the ability to access non-app friends, the Messages API becomes drastically less 
useful. It will also be impossible to build P2P payments within the RBC app, which would 
have dire consequences for our partnership with them.' 


Response email from Jackie Chang to Sachin Monga, 10.46am 20 August 2013, regarding 
Royal Bank of Canada 

'What would be really helpful for us is if you can provide the below details first: 

2/ did they sign an extended api agreement when you whitelisted them for this api? 

3/ who internally gave you approval to extend them whitelist access? Can you send me 
email or permalink from the Platform Whitelist Approval Group. 

4/ Is there budget tied specifically to this integration? Flow much? 

We need the above info foremost and we understand the context below.' 


Email from Sachin Monga to Jackie Chang, 10.58am, 20 August 2013 
'Thanks for the quick response. Answers below: 

2/ They did not sign an extended API agreement. Should they have? I didn't know about 
this... 

3/ Doug gave the approval... 

4/ There is budget tied specifically to this app update (all mobile app install ads to existing 
RBC customers, via custom audiences). I believe it will be one of the biggest neko campaigns 
ever run in Canada...' 


Email from Jackie Chang to Sachin Monga, 22 August 2013, regarding Royal Bank of Canada 

'Let's pause any action for now until we have internal discussions about this 
tomorrow...we'll do the right thing to take care of this. Thanks!' 

Email Simon Cross to Jackie Chang, Sachin Monga, Bryan Hurren (Facebook), 25 October 
2013 


'+ bryan who recently whitelisted Netflix for the messages API - he will have a better idea of 
what agreements we need to give them to access to this API.' 



Email from Bryan Hurren to Sachin Monga, Jackie Chang and Simon Cross, 25 October 2013 

'From a PR perspective, the story is about the app, not the API, so the fact that is uses Titan 
isn't a big deal. From a legal perspective, they need an "Extended API agreement" (we used 
with Netflix) which governs use going forward and should provide us with the freedom to 
make the changes that Simon mentions below (without being too explicit).' 


Email from Jackie Chang to FB group, 28 October 2013 

'Bryan - can you take the lead on getting this agreement written up?' 


Exhibit 79 - linking data access spending on advertising at Facebook 
Email from Konstantinos Papamiltidas [FB] to Ime Archibong [FB] 

18 September 2013 - 10.06am 

From email about slides prepared for talk to DevOps at 11am on 19 September 2013 

'Key points: 1/ Find out what other apps like Refresh are out that we don't want to share 
data with and figure out if they spend on NEKO. Communicate in one-go to all apps that 
don't spend that those permission will be revoked. Communicate to the rest that they need 
to spend on NEKO $250k a year to maintain access to the data.' 


Exhibit 80 - linking data access spending on advertising at Facebook 

Email from Konstantinos Papamiltidas [FB] to Simon Cross [FB], Ime Archibong [FB] and 
Jackie Chang [FB] 

Discussion about presentation Simon Cross is to give re P3.0 Rollout Planning 
4 September 2013 4.28am 

'Slide 5 - I am not sure about the revenue saved. Is this really a cost cutting exercise? 
Removing access to all friends lists seems more like an indirect way to drive NEKO adoption.' 


Exhibit 97 - discussion about giving Tinder full friends data access in return for use of the 
term 'Moments' by Facebook 


Emails discussion between Konstantinos Papamiltiadis [FB] and Tinder regarding allowing 
Facebook to use 'Moments', a term that had already been protected by Tinder 



Email from Konstantinos Papamiltidas to Tinder 11 March 2015 5.34pm 


'I was not sure there was not a question about compensation, apologies; in my mind we 
have been working collaboratively with xx and the team in good faith for the past 16 or so 
months. He's a member of a trusted group of advisers for our platform (Developer Advisory 
Board) and based on our commitment to provide a great and safe experience for the Tinder 
users, we have developed two new APIs that effectively allow Tinder to maintain parity of 
the product in the new API world.' 

Email from Konstantinos Papamiltidas to Tinder 12 March 2015 1.10pm 

'We have been working with xx and his team in true partnership spirit all this time, 
delivering value that we think is far greater than this trademark.' 


Exhibit 170 - Mark Zuckerberg discussing linking data to revenue 
Mark Zuckerberg email - dated 7 October 2012 

'I've been thinking about platform business model a lot this weekend...if we make it so devs 
can generate revenue for us in different ways, then it makes it more acceptable for us to 
charge them quite a bit more for using platform. The basic idea is that any other revenue 
you generate for us earns you a credit towards whatever fees you own us for using plaform. 
For most developers this would probably cover cost completely. So instead of every paying 
us directly, they'd just use our payments or ads products. A basic model could be: 

Login with Facebook is always free 
Pushing content to Facebook is always free 

Reading anything, including friends, costs a lot of money. Perhaps on the order of 
$0.10/user each year. 

For the money that you owe, you can cover it in any of the following ways: 

Buys ads from us in neko or another system 

Run our ads in your app or website (canvas apps already do this) 

Use our payments 

Sell your items in our Karma store. 

Or if the revenue we get from those doesn't add up to more that the fees you owe us, then 
you just pay us the fee directly.' 


Exhibit 38 - Mark Zuckerberg discussing linking data to revenue 


MZ email 27 October 2012 to Sam Lessin at Facebook 



'There's a big question on where we get the revenue from. Do we make it easy for devs to 
use our payments/ad network but not require them? Do we require them? Do we just 
charge a rev share directly and let devs who use them get a credit against what they owe 
us? It's not at all clear to me here that we have a model that will actually make us the 
revenue we want at scale.' 

'I'm getting more on board with locking down some parts of platform, including friends data 
and potentially email addresses for mobile apps.' 

'I'm generally sceptical that there is as much data leak strategic risk as you think. I agree 
there is clear risk on the advertiser side, but I haven't figured out how that connects to the 
rest of the platform. I think we leak info to developers, but I just can't think if any instances 
where that data has leaked from developer to developer and caused a real issue for us. Do 
you have examples of this?. 

'Without limiting distribution or access to friends who use this app, I don't think we have 
any way to get developers to pay us at all besides offering payments and ad networks.' 


Exhibit 78 - selected slides showing how Neko spend and relationship to Mark Zuckerberg 
and Sheryl Sandberg influenced outreach to developers ahead of Platform 3.0 launch 
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3. Reciprocity 


Exhibit 45 - discussion on making reciprocity a key feature of Platform 3.0 


Email from Mike Vernal FB, 30 October 2012 


Mike Vernal 

'On Data Reciprocity - in practice I think this will be one of those rights that we reserve.. 
We'll publish a spec for an API that you have to implement to integrate with us, we'll have 
POPS review, but we'll pay closest attention to strategic partners where we want to make 
sure the value exchange is reciprocal.' 

Greg Schechter 

'Seems like Data Reciprocity is going to require a new level of subjective evaluation of apps 
that our platform ops folks will need to step up to - evaluating whether the reciprocity 
Ul/action importers are sufficiently reciprocal.' 

Mike Vernal 

'As many of you know, we've been having a series of conversations w/Mark for months 
about the Platform Business Model... 

'We are going to require that all platform partners agree to data reciprocity. If you access a 
certain type of data (e.g. music listens), you must allow the user to publish back that same 
kind of data. Users must be able to easily turn this on both within your own app as well as 
from Facebook (via action importers) 


Exhibit 48 - Mark Zuckerberg email on reciprocity and data value 


MZ email 19 November 2012 

'After thinking about platform business for a long time, I wanted to send out a note 
explaining where I'm leaning on this. This isn't final and we'll have a chance to discuss this in 
person before we decide this for sure, but since this is complex, I wanted to write out my 
thoughts. This is long, but hopefully helpful. 

'The quick summary is that I think we should go with full reciprocity and access to app 
friends for no charge. Full reciprocity means that apps are required to give any user who 
connects to FB a prominent option to share all of their social content within that service 
back (ie all content that is visible to more than a few people, but excluding 1:1 or small 


group messages) back to Facebook. In addition to this, in the future, I also think we should 
develop a premium service for things like instant personalization and coefficient, but that 
can be separate from this next release of platform... 

'We're trying to enable people to share everything they want, and to do it on Facebook. 
Sometimes the best way to enable people to share something is to have a developer build a 
special purpose app or network for that type of content and to make that app social by 
having Facebook plug into it. Flowever, that may be good for the world but it's not good for 
us unless people also share back to Facebook and that content increases the value of our 
network. So ultimately, I think the purpose of platform - even the read side - is to increase 
sharing back into Facebook.' 

...'It seems like we need some way to fast app switch to the FB app to show a dialog on our 
side that lets you select which of your friends you want to invite to an app. We need to 
make sure this experience actually is possible to build and make as good as we want, 
especially on iOS where we're more constrained. We also need to figure out how we're 
going to charge for it. I want to make sure this is explicitly tied to pulling non-app friends out 
of friends.get.' (friends information) 

...'What I'm assuming we'll do here is have a few basic thresholds of API usage and once you 
pass a threshold you either need to pay us some fixed amount to get to the next threshold 
or you get rate limited at the lower threshold.' 


Response to this email from Sheryl Sandberg 

Email from SS - 19 November 2012 

SS 'I like full reciprocity and this is the heart of why.' 


Exhibit 43 - memo setting out the policies for Platform 3.0 

This document also stresses the importance of reciprocity to Platform 3.0 

'The fundamental principle that governs Platform usage is a simple concept: reciprocity. 
Reciprocity involves an equable value exchange between a 3 rd party developer and 
Facebook. This value exchange involves one of the following from developers: high quality 
experiences that FB users can use to tell great stories to their friends and family on FB 
and/or monetary value in the form of revenue sharing or direct payment. In return, 
Facebook offers a developers access to our Platform. 

'When considering the implications of reciprocity it is important to note that a second order 
principle quickly emerges: competitive access. There are a small number of developers 
whom no amount of sharing to FB or monetary value can justify giving them access to 
Platform. These developers do not want to participate in the ecosystem we have created. 






but rather build their own ecosystem at the expense of our users, other developers and, or 
course, us. That is something that we will not allow.' 


4. Android 


Exhibit 172 - discussion of changing 'read call log' permissions on Android 
From email dated 4 February 2015 

Michael LeBeau - 'Fie guys, as you know all the growth team is planning on shipping a 
permissions update on Android at the end of this month. They are going to include the 'read 
call log' permission, which will trigger the Android permissions dialog on update, requiring 
users to accept the update. They will then provide an in-app opt in NUX for a feature that 
lets you continuously upload your SMS and call log history to Facebook to be used for 
improving things like PYMK, coefficient calculation, feed ranking etc. This is a pretty high- 
risk thing to do from a PR perspective but it appears that the growth team will charge ahead 
and do it.' 

Yul Kwon - 'The Growth team is now exploring a path where we only request Read Call Log 
permission, and hold off on requesting any other permissions for now. 

'Based on their initial testing, it seems this would allow us to upgrade users without 
subjecting them to an Android permissions dialog at all. 

'It would still be a breaking change, so users would have to click to upgrade, but no 
permissions dialog screen.' 


Exhibit 180 - further discussion of read call log and SMS on Android 
Email from Matt Scutari, Manager Privacy and Public Policy, Facebook 
15 November 2013 

'Matt has been working with the privacy PM, PMM and Legal to understand privacy risks 
associated with several Android permissions that will go out in the next release, including 
permissions associated with reading call logs and SMS' 

'Matt is providing policy feedback on a Mark Z request that Product explore the possibility 
of making the Only Me audience setting unsticky. The goal of this change would be to help 
users avoid inadvertently posting to the Only Me audience. We are encouraging Product to 



explore other alternatives, such as more aggressive user education or removing stickiness 
for all audience settings.' 

Exhibit 158 

Facebook email discussing rapid growth of revenues from Neko advertising 

5. Onavo 

Exhibit 69 - slides from presentation showing market analysis driven by Onavo data 
Facebook 'Industry update' presentation based on Onavo data, 26 April 2013 
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Exhibit 70 - Facebook 'Industry update' presentation based on Onavo data, 15 March 2013 


US mobile apps (iPhone only) 


US iPhone App Reach, Aug 2012 - Feb 2013 (source: Onavo) 
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6. Targeting competitor Apps 


Exhibit 44 - Shutting down Vine's friends data access 
Facebook email 24 January 2013 

Justin Osofsky - 'Twitter launched Vine today which lets you shoot multiple short video 
segments to make one single, 6-second video. As part of their NUX, you can find friends via 
FB. Unless anyone raises objections, we will shut down their friends API access today. We've 
prepared reactive PR, and I will let Jana know our decision. 


MZ - 'Yup, go for it.' 
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EXHIBIT 38 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 


Sam Lessin 


Sent: 

To: 

Subject: 


Saturday, October 27, 2012 6:50 PM 
Mark Zuckerberg 
Re: notes on platform 


Back at you inline... 


On 10/27/12 1:57 PM, "Mark Zuckerberg" wrote: 

>More thoughts inline... 

> _ 

>From: Sam Lessin 

>Sent: Saturday, October 27, 2012 9:14 AM 
>To: Mark Zuckerberg 
>Subject: Re: notes on platform 
> 

>Thanks for reading it through and the response. 

> 

>-1 agree with your framing of the three questions embedded in my 
>proposal. 

> 

> 

> 

> 

>Regarding your notes on #1 
> 

>--1 do agree that 10% to 20% of a small number of businesses doesn't get 
>us there§ just as a platform with thousands of developers who pay us 
>nothing doesn't get us there. That is why I basically land on a model 
>where some APIs are widely available at scale (and we get thousands of 
>developers at scale) but there are a set of APIs that really are just for 
>partners. Also known as, I think we need to have it both ways. 

> 

>» Yeah, I think having two programs is pretty reasonable. The question 
>»to me is just what's in each program and what we get from it. My 
»>interpretation of your proposal is that we get the vast majority of the 
»>value from the companies we partner with, but I have a hard time 
>»imagining we actually have these kinds of deep partnerships with 
»>hundreds of companies, so there's a disconnect for me there. I also 
»>interpret your proposal as if we won't make very much money at all from 
>»non-partner companies, and I think there needs to be and likely is a 
>»bigger opportunity for us there. 

»>ln my model, we’ll define rev shares for as many industries as we can 
»>think of. There will always be some companies that don't fit whatever 
»>models we have or we want to give them deeper access in exchange for 
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»>more value share, and that's what the deals are for. But I'd love to 
»>get to a state where most of the value we derive is from the open part 
»>of the platform with clearly articulated rules rather than custom 
»>partnerships. 


SWL::::: I think we will get a ton of value from the companies using the 
'free' APIs / non-partners... it is just that the value will funnel all 
directly through our ads/distribution platform... which is not a bad 
outcome at all / it is seeing platform as all about just making the 
distribution business more efficient and scale better against a model 
where there is natural pricing / a market. At the same time, I do think 
that we will also get a lot of value out of the partners / which I really 
see as a set of companies / producing a set of products which we would 
probably consider building ourselves if we could... 


»> 

> 

>-- The problem I have with a rev-share directly, or forcing a developer to 
>use our payments / ad network is that we are not connecting the value and 
>the cost closely enough. If the thing that is valuable is our payments, 

>they should pay for our payments if they use our paymentsS if the thing 
>that is valuable to them is the ad network,S. The rev-share could be an 
interesting deal term at the high end, but is just too hard for developers 
>to evaluate / know the value we are driving for them and whether it is 
therefore worth it to be on the 'platform'. 

> 

»> I agree this is a big problem with my proposal. It's much easier for a 
»>developer to be able to take pieces a la carte and know what they're 
»>paying for them. Another issue that's implicit in my proposal is that 
»>it's not yet clear how a dev would disconnect the revenue share, 
»>whereas it's quite clear how you'd disconnect payments or ad network 
»>though. That said, I think there is probably a reasonable solution to 
»>these problems that would still let us get a revenue share. I just 
»>think we need to work through this a bit more. The root of my belief is 
»>that helping people sign up faster, ramp up faster and remain more 
»>engaged is fundamentally valuable. So even though it is more difficult 
»>and disconnected to value, rational actors should be able to value it. 
»>Further, I think having a market of participants will help devs value 
»>it. For example, there's no reason why 2% is a reasonable rev share for 
»>a credit card processing company to take, but since everyone else 
»>accepts it, it now seems more "reasonable" and more folks do it. If we 
»>start with the head and then open this program up more broadly, I bet 
»>we can figure out a set of reasonable revenue shares here for each 
»>industry/category. 


SWL::::: Yes, the 'how does a company disconnect' bit is a really big one 
to call out in this context. RE: the concept that helping people sing up 
faster, ramp up faster, and remain more engaged as 'fundamentally 
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valuable' -- my believe is that these things are valuable, but not at all 
infinitely valuable (actually, to the contrary, they are quite measurably 
valuable). We aren't the only ones that can help people signup/ramp up 
faster/ remain more engaged, we exist in an ever more competitive 
marketplace for these services. Also, the reality is that the value of a 
marginal customer / a customer that would 'bounce' without us is 
measurable and usually relatively low for all companies except for 
networks which are looking for initial traction.... Which begs exactly the 
question of long-term lockin. 


Think of this from our perspective. If we had had some magic 'engagement' 
product we could have bought early on as a company it would have been 
worth a ton to us in the short term / we would have paid a lot for it for 
the first few million users (just as we are willing to pay a lot to get 
early users in new markets via search ads, etc.) -- once the flywheel is 
going, it is worth something to us... but honestly not very much, both 
because we would inevitably develop our own cheaper routes with time and 
money if the cost was anything but completely nominal OR because we would 
get to the point that the marginal user isn't economically worth that much 
to us (the situation we currently face) 


Regarding your notes on #2 

> 

>-- Reading your responses, I do think you are right, I am being stark. I 
>worry about mobile messaging apps, etc. and I probably need to temper 
>that in my own thinkings the irony is I would be more comfortable with 
competition if I thought we knew better how to leverage our scale asset 
>(and if scale weren't' becoming cheaper and cheaper to achieve every day). 

> 

>-- What I think is that we should effectively not be helping our 
competitors more / much more than how they could get help from elsewhere 
>in the market. They can acquire users in ways other than usS so 
cbviously we shouldn't be failing to take their money when they will just 
>give it to someone else and get the same outcome. I do, however, again 
Chink that we want as much control here as we can get. 

> 

»> I agree we shouldn't help our competitors whenever possible. I think 
»>the right solution here is to just be a lot stricter about enforcing 
»>our policies and identifying companies as competitors. 


SWL::::: AMEN 


> 

> 

> 

>Regarding your notes on #3 
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> 

>-- On whether the things developers contribute to the system are valuable 
>to us or notS. In my mind they are really only valuable if users want them 
>/ either because they value the self expression or drive engagement. If 
>they do neither, then I do not believe that applications writing to 
>Facebook is currently worth much -- AND I believe that if they do neither 
>there are other ways for us to work with developers more efficiently to 
>get the value from the data they collect from users. 

> 

»> I think it's quite possible that developers writing to the graph today 
»>drives no incremental engagement or information targeting value for us. 
»>l do think users appreciate the ability to share things and that 
»>probably helps us somewhat, but I think users also like having the 
»>ability to take their info out of Facebook and we're considering 
»>charging for that. By charging for distribution, we'd essentially be 
»>building a way for users to access those features, but developers have 
»>to pay us for them. 

SWL:::::: I think we need to provide DLYD obviously, and you are right 
that some power-users do appreciate the ability to take data out in 
general / push it to other services.... I think this is something we can 
manage around. I do think it is basically zero cost to us to allow 
applications to write content on behalf of users, but we should just think 
of it as that -- which is allowing apps to fulfill a user need... re: the 
distribution, I don't think we should under-weight distribution from apps, 

I just don't think we should over-weight it -- and I think that if the 
real value translation is apps publish data to Facebook because users want 
to publish data to Facebook, then we should do the right thing by users 
around creating good experiences vs. worrying about pushing 'traffic' back 
to apps (aka, go with snow-box type solutions for third party photos and 
pinterest pins rather than pushing the user out to the site. 


>-- Really what this boils down to is that I think developers are rational 
>business actors. They will not give us structured data which is actually 
>valuable to us unless users demand it. 

> 

»> Agreed. 

SWL::::: AMEN 


> 

>-- Again, I think we just need to get away from thinking about a developer 
>'using' platform or not / or that we can 'tax' platform as a whole. We 
>have a series of APIs, just like amazon web services, etcS the decision 
>to rely upon / use or not use any service we provide is really an 
independent business decision. I think that saying that in order to 
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>'publish' to Facebook, or in order to get a UID for one of your users you 
>must implement our payments or ad-network, or pay us a percentage of 
>revenue is just too abstract for rational decision makings 
> 

>» I'm not sure I agree with the overall point here. I agree it would be 
»>ideal if we could make everything a la carte efficiently, but it 
»>doesn't seem like we can do that and that realization is leading us 
»>down a path of minimizing development and access to an important piece 
»>of platform that I think devs do value (the read side). I do agree it's 
»>difficult for a dev to think about whether the value exchange is fair 
»>theoretically, but if we can get a few folks on board then I think we 
»>can start to establish a market norm and more folks will do this. 

> 

»> In some ways, I actually think an overall tax is the most efficient 
»>way to do this. If the most valuable aspect is distribution and if 
»>charged a la carte for that, then I do think that would encourage 
»>developers to be sparing and economically efficient about when they 
»>write data to Facebook. Flowever, if we have an overall tax and then 
»>writing is free within that, then their incentive is to get as much 
»>value out of the integration that they're paying for as possible. 

SWL::::: I don't agree -- but I do understand your perspective. I really 
just can't see any developer making the % revenue trade with us for a 
bundle of services some of which they value, others of which they may not, 
and overall where it is really hard for them to know what is what 
(especially over the long term) 


> 

> 

>-- Today we have (or think we have) more efficient engagement and 
>re-engagement tools than anyone else, and we pretty much have a functional 
>way of pricing it and having developers rationally evaluate paying for it. 

> That is greats. We should be leveraging that all the way 

> 

>-- Today we also have some functions on a platform which our users want, 
>we are at least neutral on, and therefore developers implement (ideally). 

>lt is unclear exactly how much our users want the functions, but the 
>things that are strict user benefit and no cost to us we should produce, 
>though we should think of the eng tradeoff / just as another feature of 
>Facebook. 

> 

>-- Tomorrow we should have things like a payments solution and ad-network, 
>which should be better than everyone else's / should be able to compete in 
>the marketplace on their own; however, only marginally so — and as a 
>result probably not in a way that we can rationally demand a huge premium 
>(though I am sure we can demand some premium) 

> 

»> It's not clear to me that our solutions here will be automatically 
»>better than alternatives for a while. And even if they are better, then 
»>what we have is a payments or ad network platform and we still don't 
»>have an information platform. This is part of what I don't get here. If 
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»>the value is in the information platform (read/write) then trying to 
»>make money from payments/ads seems pretty disconnected and inefficient. 


SWL::::: I hear you... basically tho, my view is that we should only develop 
payments APIs if we have a reasonable belief that we are going to be able 
to provide better payments APIs than competitors (more cost competitive, 
etc.)... Same with an ad-network... valid things for us, but they have 
nothing/little to do structurally with being an information platform 
directly when presumably if all we want is the 'data' that comes off of 
having an ad-network, or the 'data' that comes off of having a payment 
platform we can get that information other ways. 


> 

>-- Finally, if we are going to have another return on scale business other 
>than attention, we need for that business to stand on its own / be a 
>rational trade in and of itself for us and for developers. Unfortunately, 

>the dynamics around data are just complicated enough that I think we end 
>up in a world with maybe 100 or 200 partners for the next few years, not 
>everyone -- and we have templatized, but not formalized terms. 

> 

»> I generally agree with this point, but I wonder if we can't both get 
»>to scale in terms of getting people to write to us and also get them to 
»>pay us for it. As an analogy, it's good for us that devs build games 
»>inside FB. We could have made the argument that it was good for us so 
»>we shouldn't tax them, but in reality by taxing them I just think we 
»>got to a state where we both got the games and made more money. We 
»>likely lost some games, but I think we generally maximized profit. 

> 

»> Overall, I'm just pretty optimistic about this idea of being an 
»>"identity" service and establishing that as a layer of the app 
»>development stack so the norm is that developers pay for it. Maybe 
»>identity comes with the ability to push content to a person's friends, 
»>or maybe it just comes with the ability to ramp up a new user more 
»>quickly and connect them to friends and interests. But this does seem 
»>like it should be a real thing to me that should stand on its own and 
»>not just be a loss leader to push lower margin payments and ad networks 
»>products. 

> 

> 

SWL::::: I believe we should always charge what the market will bear to 
others companies in the ecosystem... but not more than what the ecosystem 
will bear. For payments, or an ad-network, we have competitors. Either 
we can produce better products in these spaces which in a head to head 
competition can beat other solutions on value, or we can't. IF we can, we 
can make money, if we can't then we will not. Same goes for our 
distribution business. 

In the canvas case, developers basically had no other option when platform 
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was succeeding for games. Now we compete with the mobile platforms, and 
while we still have a decent enough position for games to generally get 
away with taking real-estate on web + 45% of revenue, I also think the 
best developers / the best games have left, and what we really have is a 
set of games made by people who see a financial opportunity to hack our 
system for free attention... I am not proud of the fact that we are 
currently extolling 'game' companies that make online slot machines as 
positive examples of those willing to pay our fees (I am fine with it, 
just not proud of it) 

I am totally bought into our identity business in the sense that giving 
apps the ability to uniquely get identifiers on all their users is a huge 
huge deal... the question is only what do you do with that / how do you 
match it up with an economic model... and I think we need to couple the 
identity value + services, where our services are better because of 
identity (be they engagement / re-engagement, an ad-network, or payments 
with better built in fraud detection).... The only thing we should be 
careful of is making sure that we are selling things in ways developers 
can rationally evaluate and want. 


SWL:::::: Obviously happy to (1) continue this conversation (2) not 
continue it if the marginal value is now too low.... One thing I intend to 
do next is basically wireframe out very roughly what our developer landing 
page / sales page, could look like under a more 'holistic' % fee scenario 
and under a more a-la-carte model. I think that putting some practical 
screens up on how things could look in mid 2013/2014 might be helpful... 


Sam 


> 

> 

> 

> 

> 

>On 10/27/12 6:06 AM, "Mark Zuckerberg" • wrote: 

> 

»l think I understand your proposal. 

» 

»lt seems like it really comes down to three main questions: 

» 

»(1) What is a revenue model that scales to build the kind of business we 
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»want? 

» 

»(2) What is a read model that reduces the strategic risk to our business 
»(and doesn't undercut that revenue growth)? 

» 

»(3) What is a model that developers will participate in rather than 
»abandoning? 

» 

»Now going through each of them... 

» 

»For (1): 

» 

»-1 agree with your argument that we need to get some value proportional 
»to the value we create as opposed to a fee on our costs for this to work. 
»l'm generally sold on that. 

» 

»-1 also agree with your argument the other day that whatever we do needs 
»to be very widely adopted. Having 10-20 partnerships where we own 10-20% 
»of the companies isn't where we want to be either. The underscores the 
»importance of question (3) and developing a model that many developers 
»will go for. I am not sure how this foots with doing a lot of of specific 
»deals though. In theory we could do an infinite number of deals, but in 
»practice a strategy of making deal seems explicitly like a strategy to 
»work with a smaller number of companies, which may by itself prevent us 
»from reaching the long term revenue goals we have. 

» 

»- There's a big open question on where we get the revenue from. Do we 
»make it easy for devs to use our payments/ad network but not require 
»them? Do we require them? Do we just charge a rev share directly and let 
»devs who use them get a credit against what they owe us? It's not at all 
»clear to me here that we have a model that will actually make us the 
»revenue we want at scale. 

» 

»For (2): 

» 

»- I'm getting more on board with locking down some parts of platform, 
»including friends' data and potentially email addresses for mobile apps. 

» 

»- I'm generally skeptical that there is as much data leak strategic risk 
»as you think. I agree there is clear risk on the advertiser side, but I 
»haven't figured out how that connects to the rest of platform. I think we 
»leak info to developers, but I just can't think of any instances where 
»that data has leaked from developer to developer and caused a real issue 
»for us. Do you have examples of this? 

» 

»-1 also think your argument about not selling down our advantage is too 
»rigid. Businesses pay for new customer acquisition and then for 
»reengagement. Eventually you run out of new customers and need to focus 
»more on reengagement. We shouldn't prevent ourselves from helping 
»business get new customers just because one day they might run out of new 
»customers to acquire. It doesn't scale infinitely, but it does scale 
»pretty far. 
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» 

»-1 also think your argument about how we help competitors is too black 
»and white. In reality, we do this with distribution too. We let most 
»competitors buy ads. And even if we didn't, we'd let other media 
»companies buy ads, and then our competitors could buy ads from those 
»companies. At some level I think helping your competitors is a fact of 
»life. We need to make sure we're not doing this to an extent that it 
»destroys us, but we also shouldn't be so rigid as to rule out any model 
»where competitors get benefit from us. 

» 

»For (3): 

» 

»-1 think what developers will be willing to bear is the biggest open 
»question here. No one knows this for certain and a huge amount obviously 
»hinges on this. 

» 

»-1 do agree that if we give away distribution and login for free, then 
»basic info alone isn't enough value to command a meaningful revenue 
»share. 

» 

»- That said, this makes me wonder if we need to question our assumptions 
»on what we want to be free. If what developers mostly value is 
»distribution (which we're currently not charging for), then I think we 
»really need to ask the question of whether we're actually getting value 
»from this. In theory we want information, but are the posts developers 
»are giving us actually valuable? They don't seem to be for targeting and 
»l doubt they drive meaningful increases in engagement either. That 
»suggests that from an information perspective perhaps these aren't so 
»valuable for us. They aren't negatively valuable, but if there's a big 
»disparity between what developers get and what we get then perhaps 
»charging for this isn't so crazy. I'm not yet convinced this is the right 
»thing to do, but it seems at least worth thinking about to me. If we were 
»strategically okay with not giving this away for free, then I think many 
»more developers actually would accept a rev share to enable their users 
»to connect with FB and share back to us. If we did this, we'd see some 
»dropoff in developers, but I'm not sure how much. The distribution is 
»very valuable for developers and as long as the rev share isn't onerously 
»high then I bet most would stick around. And counterintuitively, once 
»devs were paying for this, they'd probably be more invested in getting 
»the most out of the integrations so they'd likely invest more and 
»actually push even more info into FB. 

» 

»- Without limiting distribution or access to friends who use this app, I 
»don't think we have any way to get developers to pay us at all besides 
»offering payments and ad networks which can stand by themselves and 
»compete with other companies' services. But at that point we still don't 
»really have a sustainable platform; we just have a good payments service 
»and ad network. So that might make us more money, but over time we'll 
»shift our energies towards building those services and we still won't 
»develop a great platform. 

» 

» 
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» _ 

»From: Sam Lessin 

»Sent: Friday, October 26, 2012 10:51 PM 
»To: Mark Zuckerberg 
»Subject: notes on platform 
» 

»Zuck, 

» 

»l have been going through iteration after iteration on the platform story 
»trying to suss out a perspective that feels strategically right in the 
»long term / as a set of guiding principles AND which is implementable and 
»functional in the short term. Obviously I know you have been thinking 
»about this a lot as well (along with a lot of other smart people) and I 
»am happy to get behind and drive whatever you want to land on; however, I 
»do want to try to share my full thinking with you / the perspective on 
»which I have landed. This is longS sorry. 

» 

» 

»Uncharacteristically, I would like to start with what I think we should 
»practically do, and back out to the 'why' rather than visa versa. 

»Practically, I strongly believe that we should operate platform in the 
»following way: 

» 

»(1) Applications can write to the graph freely. 

» - (A) They can write information on behalf of a user to the user's 

»timeline (so long as they have collected the necessary 'write' 

»permission) 

» - (B) They can write information on their own behalf (in the voice 

»of a 'page 1 , as an 'advertisement', adding information to their CRM 
»against a UID, email, etc.) 

» - (C) We can choose to show the content they write to the graph on 

»their own behalf or that of users in newsfeed as we see fit / to maximize 
»the consumption experiences and if applications want they can 'boost' / 
»trump the auction 
» 

»(2) Applications can use 'Facebook login' freely & have many avenues to 
»getting user's IDs 

» - (A) Any app can choose to have their users login with Facebook, 

»and if they do we will give them the user's UID (not a hashed ID)S 
» - (B) We will / can also open up other avenues for giving 

»applications UIDs / Identifiers that allow them to better leverage our 
»system (via email matching, invisible pixels, cookies perhaps, mobile 
»tracking, etc.) 

» - (C) We need to have terms that make it clear that sharing UIDs 

»across applications is not OK, and stringently enforce 
» 

» - (D) We should develop things like a payments API that sits on top 

»of these IDs and has its own fee structure at a flat rate 
» - (E) We should develop things like an ad-network that sits on top 

»of these IDs and has its own structure for paying developers at a 
»market-defined rate 
» 
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»(3) - Reading 'Basic Information' freely 
» - (A) Applications can ask permission of users to read 'basic 

»information' which a user would otherwise provide when registering for 
»their service freely 

» - (B) Applications can ask for the UIDs of a user's friends who is 

»also using their applicaiton freely 

» - (C) Users should be actively encouraged to engage with the 

»information they are giving applications 
» 

»(4) -- Reading/Using Non-'basic' Information & functions 
» - (A) We should develop a whole set of non-basic information 

»datasets and APIs which encompass: 

» -- (1) User Data which doesn't reasonably fit into something 

»which an application could ask for themselves as part of registration / 
»which other services cannot provide 
» -- (2) Facebook insights / data (coefficient, trust, etc.) 

» -- (3) An Oracle APIS for things like 'twinning' / making 

»specific decisions about a user based on a application provided signal 
» -- (4) Eventually, a brokering business where applications 

»other than Facebook can provide insights to other applications (and we 
»can run a marketplace in-between) 

» 

» - (B) These data-sets become leverage able openly via our 

»ads-trageting / distribution channels 

» - (C) We can provide some sort of very low testing limit on most of 

»these APIs for free, but to use them at any scale is a conversation with 
»our BD folks. 

» - (D) These APIs are best thought of as white-list / internal APIs 

»which if you are owned by us, or a close ally, we will open them up for 
»you. 

» 

»(5) - Competitive exclusions & stuff to deprecate / change that now 
»exists 

» - (A) We should dramatically increase our enforcement of competitive 

»exclusions, and actively suggest to application developers that even if 
»they are small they should check with us first if they are worried about 
»our definitions 

» - (B) We should turn off all APIs that don't fit the 'registration' 

»litmus test of #3, while maintaining them on a 'white list' basis for 
»bucket #4 if we want (things like the full friends.get, the messaging 
»APIs, etc.) 

» 

» 

»Upshot: where this nets out for me is that we end up with S. 

» 

»-- (1) an open, stable, and free platform for writing data to Facebook, 
»getting the information you need to wire up a set of users you have 
»engaged, and all the IDs / hooks you need to actively participate in our 
»attention market (buy ads) as well as leverage any other services like 
»payments or an ad-netowrk we may want to offer in the future 
» 

»~ (2) an ever increasingly valuable set of proprietary APIs for richer 
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»information, etc. which are not openly available beyond perhaps a 'free 
»sample', but which allow us to 'project' into the ecosystem the value of 
»a *hopefully* ever deeper data-setsS. giving us the ability ^hopefully* 

»to participate in a variety of deeply socially enabled businesses which 
»ideally we would build ourselves if we could, but in a heterogeneous 
»enough set of industries with different margins and properties that it 
»would be impossible for us to price effectively. 

» 

»-- (3) we have some 'starter' APIs which are free, and then we try to 
»directly associate the cost of a given API for a developer with the API's 
»value to that developer, rather than trying to subsidize one API with 
»another, or put developers in a hard to measure / opaque position where 
»they don't exactly know if using platform holistically is worth it to 
»themS so where there is an easy way to do that (advertising on FB, ad 
»network on app partner, payments API) we can have very transparent 
»pricing, and where it is not easy to do that we have to have a 
»conversation / negotiate. 

» 

»-- (4) the messaging to the ecosystem becomes that we are deprecating a 
»few things for privacy reasons / to simplify our model for users, we are 
»enforcing non-competitive terms we have always had, and we are opening up 
»a series of new white-list APIs for the best companies that want to build 
»the best social services and want to work with us deeply. 

» 

» 


» 


/V/V/V(V/Vf«/V/V»V/V/V/V/V/V/V/VfVfUfV 


» 

»The above stated, let me try to justify its starting by walking through 
»the incentives / perspectives of each of the parties to our system. 

» 

»Users (in brief) 

»The user incentives around platform are pretty straight forward in the 
»abstract / long-term, though there are some quirks to pay down 
»shorter-term. Over time, users just want to have amazing experiences in 
»the physical and virtual world enabled by social. First, they want great 
»apps where they can find and interact with great content and experiences 
»with their friends. They certainly don't want to have to 'sign in' to 
»anything with different passwords, etc. Over time I think they will want 
»applications to help them express themselves so that they can have more 
»custom experiences / better experiences of the world, and I think they 
»will eventually appreciate things like ever better targeted 'ads' as a 
»real benefits I also think they fundamentally want control. 

» 

»Developers/Businesses (in brief) 

»Developers are rational actors that fundamentally want to make as much 
»money as possible. Plain and simple. The days of application developers 
»without a business model / building projects for fun are rapidly 
»disappearing. There will always be people hacking / playing, and every 
»once in a while we will have a chat roulette, but the reality is that the 
»app ecosystem has professionalized and anyone building anything of scale 
»/ import are going to act like rational consumers of services / APIs. To 
»run businesses, what developers need from us is the following (1) 
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»Stability. They need to be able to project / model forward for years at 
»a time in order to get cheap capital to build, and know how to 
»efficiently and effectively scale their businesses (2) Measurability. 

»They need to be able to know what their costs are going to be, and how to 
»maximize their profits efficientlyS which means that the easier we can 
»make it for them to tie together costs / revenues / and profits the 
»better (3) Services which make them more efficient than their competitors 
»at acquiring, re-engaging, merchandizing / creating great user 
»experiences, and monetizing their users. (4) Strategic flexibility / 

»option value that translates into valuation. There may be some minor 
»value for developers in having fewer partners vs. using a wider range of 
»services by different providers, but ultimately in a world of well formed 
»APIs they will swap in-and-out providers at will to get the most 
»effective systems / cheapest rates / etc. 

» 

»Facebook (in a tad more depth and with a detour through our business 
»model) 

»Our mission is to make the world more open and connectedS and the only 
»way we can do that is with the best people and the best infrastructure — 
»which requires that we make a lot of money / be very profitable. My 
»assertion is that for us to be very profitable over a long time, we have 
»to be in businesses / have a business model where we get more profitable 
»the bigger we are (a return on scale business)S. Conversely, we cannot 
»be in a commodity business or 'sell off our assets in a way that 
»transfers wealth from ourselves to others. 

» 

»There have been three paths to sustainable robust margins historically. 
»(1) regulation / having a powerful monopoly like a state dictate that you 
»are the only way to do something (2) proprietary expertise / knowing 
»something or having the structural ability to produce goods and services 
»that no one else can (the coke formula) (3) being in a business with 
»natural return on scale dynamics (where you are more profitable because 
»you are bigger)S. Neither regulation nor expertise are actually good 
»ways to be a non-commodity business for us. Regulation is obviously an 
»unappealing course / not at all interesting, and is something I list only 
»for completeness/looking at history. Expertise doesn't work when 
infrastructure is commoditizing rapidly & given the talent dynamics of 
»the technology industry. Return on scale must be our bet as a companyS. 
»so, we need to focus on businesses where we are better / more profitable 
»than everyone else because we are bigger than everyone else. 

» 

»Currently, the thing which we provide which is not commodity / where 
»there is real return on 'scale' is DISTRIBUTION at 'scale's the reason 
»that distribution has return on scale dynamics is largely because a 
»certain set of 'brand' advertisers crave it deeply, and they have very 
»few options for buying it (Facebook vs. TV). Brand Advertisers crave 
»'scale' for three reasons (1) they are in businesses themselves where 
»they are profitable enough that it is worth them talking to a huge number 
»of people imprecisely in order to reach just a few new customers (2) They 
»have developed expertise in generating an image / content where an 
»initial paid marketing buy gets supplemented with word of mouth / free 
»social diffusion of their message over time and space (3) They have 
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»developed the ability to measure / feel like they can measure the 
»effectiveness of how they spend. 

» 

»However, the problem is that most businesses (local, etc.) don't fit into 
»the bucket where they can advertise on a 'brand' basis. (1) they aren't 
»profitable enough to speak to many people imprecisely to just reach a few 
»new customers (2) they don't have the expertise to generate the creative 
»they need to get 'free distribution' multiplier (3) They can't measure 
»well enough to know what to spends, upshot, not everyone can be a brand 
»advertiser, actually most people can'tS. There are also several problems 
»with 'brand' advertisers being our 'non-commodity' business S. (1) there 
»are new ad networks / platforms / tools which chip away at the 
»defensibility / non-commodityness of 'scale', (2) we are running out of 
»humans (and have run-out of valuable humans from an advertiser 
»perspective) (3) brand advertisers will get better, but they aren't that 
»good at measuring their spend, so they have finite budgets. --The 
»upshot of which is that while being 'big' does provide us a return on 
»scale currently, it isn't something which we are going to be able to more 
»than 2X-4X in my mind anytime soon, and in some ways I think we will face 
»increasing pressure on the value we derive from our distribution scale. 

» 

»The second thing which we provide which is non commodity / where there 
»*may be* return on scale is 'information' about peoples this is far less 
»tried and true than the return on scale of distribution, which is well 
»understood and practiced! but as far as I can tell, it is the bet we 
»need to make as a company if our ambitions are long-term and grand, and 
»to me at least it feels right. For instance, if you look historically, 

»it was in many ways information which actually got us 'scale' rather than 
»visa versa. One of the things that puts us currently in a very 
»defensible place is the relationship we have created between people using 
»Facebook all the time, and us having the information we need to make 
»Facebook a better product. This is the fundamental insight in something 
»like coefficient. We know more about what people want to see because 
»people look at more stuff on our platforms In this respect, while there 
»are other ways to get close, it feels viscerally correct that there is an 
»ROS dynamic at playS the more people that use the system, the more 
»information we have on how to make more people use the systems. 

» 

»The challenge comes in not when we use the scale of our own information 
»to drive our own business platform, but when we try to leverage the 
»information with other parties to the system / businesses S which we 
»want to do on the premise that we practically cannot build everything 
»that can benefit from 'social 1 / the information we have for a hole host 
»of reasons. The first part of the challenge is that packaging 
»information alone is not valuable, rather, the value of information at 
»scale must be expressed indirectly / through other vehicles. The second 
»part of the challenge is that because information is infinitely copyable, 

»it is hard to 'sell' without giving others 'scale', and since the value 
»of scale is always relative / not absolutes so the risk becomes that by 
»monetizing your value you also destroy your value (because generally 
»people only need by information once, and two entities with the same 
»information will race to the bottom on the price of re-selling that 
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»information since there is no cost of goods sold). 

» 

»With these challenges in mind, there are two clear channels via which to 
»monetize information (1) Advertising / engagement & re-engagement 
»(lnformation makes distribution more efficient / effectively ads a 
»multiplier to our first return on scale business) (2) Merchandizing / 
»customization (Information allows companies / people to do better things 
»for their customers, on top of which they can scale revenue and 
»profitability NB: things like risk assessment fit in here). 

» 

»Mixing information with distribution to create value you can measure is 
»relatively straight forward. You simply allow ways of targeting messages 
»extremely narrowly / leveraging everything known about any person. This 
»effectively makes advertising more efficient / contextual. The 
»efficiency gains in the system create more margin for us to take. The 
»best part about this is that the market should 'price' the information 
»efficiently over time. You do still risk 'leaking' information via 
»clicks on ads, etc; however, this is a very slow leak, and can be mostly 
»dealt with via policies / limiting the use of data to the party that ran 
»the ad. 

» 

»Converting information into better 'merchandizing' means giving a third 
»party the data to use as they see fit. There should be a bunch of value 
»here, but there are also a lot of issuesS. specifically, unlike the 
»distribution market where there is a real / natural scarcity and everyone 
»competes in one finite marketplace (ultimately bracketed by the 24 hours 
»in the day), the value to a developer of being able to provide better 
»'services' is extremely conditional on who the business is / what they 
»do. It varies widely from industry to industry and company to company 
»and can changes dramatically based on exactly what information exists / 
»is exposed to them via the system. 

» 

»UpshotS the number one threat to Facebook is not another scaled social 
»network, it is the fracturing of information / death by a thousand small 
»vertical apps which are loosely integrated together. This will either 
»happen because there is fundamentally no 'return' on the centralization 
»of information / the graph OR it will happen because we sell off the 
»graph piecemeal for less than it is worth and in the process destroy 
»efficiency and value. 

» 

» 

»When User/Developer/FB incentives meet / come into tensions 
»Where I come out is that there are (1) parts of platform where we benefit 
»from everyone interfacing with us, like apps publishing for users and 
»apps having Facebook IDs for their users. We don't want to tax those 
»actions directly / we just want them broadly and widely adopted because 
»they drive value for our users and for us in the form of services you 
»enable on top of them. That said, we also don't want to orthogonally 
»subsidize them. If users don't want apps to publish for them / we can't 
»create a compelling enough experience, then we should fix that rather 
»than subsidizing / incentivizing with orthogonal value to developersS 
»(2) There are other parts of the platform that we currently provide which 
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»have some value, but the value is not very deep or meaningful (basic 
»info)S we hypothetically could charge for those parts of the platform, 

»but it wouldn't be enough money to matter at this point -- it is too easy 
»for applications to get it elsewhere (3) Finally, there is what I hope 
»can become / will be the deep value of Facebook (something like 
»coefficient)S the problem is that where the deep value is we don't want 
»to under-price the value, or over price what an app is willing to pay -- 
»and that forces us to basically just give a taste and then be ready to 
»negotiate dealsS. going line by line — 

» 

» 

»Applications *should be allowed* write to the graph freelyS. 

»- Currently rational applications / the free market of apps currently 
»write to Facebook primarily because we give them 'free' distribution 
»(engagement and re-engagement), and they do so in a way which maximizes 
»the free resource we give them over user value / demand right up to the 
»line where a user would 'un-install' the app / not give them the right to 
»publish on their behalf. While that makes logical sense as a game plan 
»for them, what we want to be the case (and is the case for some of our 
»favorite apps like Instagram) is that they write to the Facebook graph in 
»order to provide user value / because users demand it to express 
»themselves. We are still pretty far away from being in a place where the 
»app writes to the data for the publishing user, and where we show that 
»content on the publishing user's timeline, and to people in feed as a 
»user value, but the only way that a free and open publishing channel 
»works is when it is moderated by invested users and both sides of the 
»equation are factoring for their benefit. -- UPSFIOT / uncontroversial; 

»we don't want to limit the ability for apps to write on behalf of users 
»openly and freely, but we need to keep investing to make sure that users 
»are moderating it / want the apps to do its apps also should obviously be 
»able to write on their own behalf (as a page, CRM data, etc) at wills and 
»if the data they are writing on behalf of users and or their own behalf 
»helps them target ads better / acquire or re-engage users more 
»efficiently, that is good / healthy for the whole system. 

» 

»Applications *should be allowed* to use 'Facebook login' freely & have 
»many avenues to getting user's IDs 

»- Applications currently use Facebook connect by-in-large in order to (1) 
»get the 'friend' graph that enables their service to be compelling, (2) 

»get the publication rights that resolve to free distribution for them (3) 
»sometimes for the minor benefit of speeding signup* (though in reality FB 
»converts worse than non-FB signup in many cases now) (4) sometimes for 
»the minor benefit of providing easier login for users, (5) in a very few 
»cases for specific access to a specific type of Facebook data (photos, 

»etc.)S what they don't do in general is implement Facebook login in 
»order to get user's UIDs and thereby better engage/re-engage them, 
»advertise more effectively, and/or in order to use things like a connect 
»payments solution or get higher CPMs/CPCs on a future tense advertising 
»network. The trade we should be pushing on / trying to establish with 
»companies is not that Facebook login is in-and-of-itself good, but that 
»by doing it we end up providing you as a company easy to understand, and 
»easy to value benefits either on the cost side or the revenue side of 
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»your business. —UPSHOT: Right now I believe that if you asked an 
»application to implement Facebook connect but didn't give them the friend 
»graph, publication rights in the same dialog, etc. people would have no 
»reason for implementing it at all. There is no direct value for 
implementing FB connect. I think that as we add / if we add good 
»services on top of FB connect / having users logged in like payments/ad 
»network (which monetize on their own obviously) and better paid 
»acquisition channels (which are easy to create a marketplace around and 
»are easy for apps to measure / evaluate, then we have businesses in those 
»areas, and we will want FB connect distributed as widely as possible / we 
»will not want to charge for it. 

» 

»Applications *should be allowed* to read basic information freely 
»- Applications currently get a bunch of 'basic information' and users are 
»not confronted with exactly what they are giving to apps. We give out a 
»lot of things under 'basic information', some of which really weaken our 
»competitive position like 'email addresses' by opening up a non-facebook 
»channel for applications to reach out to users. This has troubled me 
»greatly; however, I have come to terms with the fact that for friends 
»already using the app, we simply can't remove what we have already 
»promised and enabling the function provides a ton of user value / value 
»for the world while still making the app go back through our platform for 
»real new-user acquisition. For things like email, name, profile photo, 

»etcS making these signup elements slightly easier for an app certainly 
»erases some cost / makes the app more valuable, but we really aren't in 
»competitive landscape where these things have meaningful value / where we 
»could charge a lot for them. First, a user will just give them to the 
»app if the app is good. Second, tons of other people like apple can now 
»give out the same information. — UPSHOT, we should give this 
information away because it has become worthless to us and allowing users 
»to give away their own basic info provides value to them. 

» 

»Applications *should be allowed* to read/use non-'basic' Information & 
»functions with some key caveats 

»- A scant few applications currently really use any of the APIs we offer 
»beyond the basic information APIs. Most of the companies that use these 
»APIs (message send, photos export, feed.get, etc.) exist in a competitive 
»grey zones generally speaking though, there isn't currently all that much 
»more you can do with our platform (though we have contemplated a lot of 
»things that would add a lot of value to other partners). This is the 
»category where I would put all my eggs in terms of building a dataset 
»which has real return-on-scale dynamics / our actual information 
»monetization schemes As we build up value in this type of data we should 
»certainly / will certainly feed it into the market-mediated ads system. 

»That should easily create more value for all if enabled widelyS the 
»question is who do we give the actual data out to and on what terms. 

»Here we face an issues, which is that the same data is just worth 
»massively different amounts to different players. If we price it too 
»high apps will not consume it, if we price it too low we are giving away 
»one of our only scaleable profit centers. If we give it to competitors 
»we are sewing the seeds of our own destructions and if we give it out on 
»any general model we are going to lose the ability to effectively 
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»negotiate with people where we really want a piece of the action / a 
»tight business. -- UPSHOT, we should sell this, but I just don't see 
»any way we can sell it on standard terms. 

» 

» 

» 

»Some select objections and responsesS. 

»A few things that I don't like about this proposal but I have come to 
»terms withS. 

» 

»We should monetize more of the 'read' side of FacebookS like basic info, 
»or connect, etc. 

»The problem is that the basic platform just isn't worth that much outside 
»of perhaps 'friends also using this app' which with the apple deal is 
»rapidly on its way to commoditization as wells AND every calculation we 
»have seen shows either that we can't make enough money from the current 
»version of platform for it to matter to us / even with generous 
»assumptions over a fairly long time OR it seems prohibitively expensive / 
»not worth it to our developers (with the exception of people that make so 
»much money they wouldn't notice). 

» 

»BD deals / any structure that relies on them crushes innovations. 

»This is generally true, BD sucksS entrepreneurs don't want to talk to 
»people or wait days to get something they need. That said, this proposal 
»is basically that the core of the APIs where there is rational value 
»exchange, etc. is open and frees and I would argue that the people that 
»will want to use our higher end APIs are going to be more sophisticated 
»people anyway / at least for a long time. We should invest to make this 
»as painless as possible, have a 1 hour turnaround time, etcS. but I just 
»keep coming back to the fact that I actually really want to / think we 
»need to talk to every person who wants to leverage our higher-end data. 

» 

»Not having transparent pricing will make people wary to invest in the 
»platformS 

»TrueS again though, it is a specific part of platform which I am saying 
»we require BD for, not the whole thing. 

» 

»We suck at picking winners / BD will force us in that direction and as a 
»result we will miss big opportunities 

»Probably true, but again, better than the alternative, and the APIs that 
»are 'free' under this model really should be enough for all but the most 
»sophisticated businesses to get up and running. 

» 

» 

» 

» 

» 

» 

» 

» 

> 
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EXHIBIT 43 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



Platform 3.0 Plan 


The following outlines the changes that we are planning to announce 
with the roll out of Platform 3.0. We will announce all of these 
changes out at the same time in a single blog post that starts the 
clock ticking on a 90-day migration. This 90-day migration window is 
the standard that we adhere to in Platform and helps developers handle 
large changes in features (this is especially important for native 
mobile developers which have a much longer lead time). We will make all 
API/permissions changes available in the migration so developers can 
test against these changes. We will make the review tool and new APIs 
available before the migration takes effect. We will make all 
tooling/policy changes available on the day the migration is turned on 
by default. 

Timing 

We have the following rails that will inform the timing of our 
announcement and roll-out. Our next migration window opens on Dune 26. 
If we decided to snap to this date that would put these changes live on 
Oct. 2nd. In terms of implementation, looking at the schedule for app 
review and SWAG for the APIs, it appears that the needed functionality 
should come online in August. Based on the above, a reasonable schedule 
is the following: 

1. Dune 26: Announce Platform 3.0 on the developer blog, making the 
API/permission changes available under a migration. 

3. Aug ??: Bring the App Review tool and new APIs online start testing 
with a limited set of developers. 

4. Oct. 02: Default the migration to on and review all new apps. 

5. Oct. 14: Begin to review apps for policy violations. 

[Note: Need to talk to Sean about the impact of these changes on games 
developers to see if this schedule works. We may need to accelerate the 
API development. Ideally we could be in position to have the new APIs 
in beta when we announce the migration.] 

Changes to Permissions and APIs 

Facebook Replacement APIs: We are removing the ability to request 
permission and read data from the user's stream, notifications, and 
inbox (message/thread). These features are used primarily for apps that 
attempt to recreate the Facebook experience on other devices. We will 
still make these APIs available to a limited number of select partners 
were it makes sense (phone OEMs, etc). 

Friends Data: We will reduce the scope of the friends-* data that a 
developer can request and access from users. Specifically, we will 
change the /friends Graph API connection to only return the user's 
friends that are already connected to the app. In addition, we will no 
longer support friends_* permissions or data access. 
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New APIs: In order to help developers address scenarios for which they 
utilize the above APIs, we are going to make two new APIs available: 
Suggested Friends and Recommendations. Suggested Friends will help 
developers pick the right app friends and non-app friends to invite to 
the app. Recommendations will help developers recommend various OG 
objects based on their friends likes and OG activity. 

App Review & Reciprocity 

Since the launch of Open Graph in lan. 2012, we have moved toward an 
app review model were we review and approve an apps integration with 
Facebook social channels (News Feed, Timeline, etc.). We extended this 
model to the App Center. With this announcement taking the next step in 
this evolution. In 90 days, we will begin to review and approve all 
apps that integrate with Platform. This will ensure that we are 
maintaining a high-level of app quality and that our user and developer 
interests are aligned. Developers may continue to develop and test on 
Facebook Platform as they always have, but before they can take their 
app "live" to non-developers/testers, their app must be approved and 
reviewed by Facebook. 

As part of this review process, we will examine the quality of the app, 
but also if the app is in compliance with our policies. In particularly, 
we will determine if the app is following our reciprocity and 
duplicative functionality policy. All apps may use Platform for Login 
and Social Plugins, but if the app accesses extended user information 
such as the friend graph, photos, etc. the app must also make it 
possible for the user to bring their data from the app back to Facebook. 
In order to help developers with this requirement, we are releasing 
tools collective known as Action Importers. 

Further, for the small faction of developers who's app may duplicate 
existing FB functionality, we can make this determination at review 
time, before the app launches, to ensure that can work together to see 
if we can come to an equitable resolution. 

Canvas Redirect Policy 

We have had a long-standing policy prohibiting canvas apps from 
redirecting outside of FB. As the ecosystem has developed, we have seen 
more and more web sites create canvas app with the sole goal of gaining 
access to bookmarks and requests for there web apps outside of FB. In 
90 days, will begin to enforce this policy in earnest. Canvas apps that 
exist that chiefly exist to redirect to external web sites will be 
disabled. For developers that were relying on this mechanism to gain 
access to requests, we recommend that they utilize the Send dialog to 
implement their request/invitation functionality. 

Page Apps (optional/for discussion with Mike/Dan) 
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There are a number of apps that are utilized to manage pages. 

Previously, an app could ask for the manage_page permission and access 
the page feed, post to the feed, etc. Moving forwarding, securing 
access to this permission and the Page API is limited to specific apps 
that offer compelling functionality above and beyond what is available 
on Facebook. For developers building page management apps, they can use 
this permission for developer/tester owned pages during development, 
but need to be explicitly approved via our App Review before they can 
ask any user for this permission or manage pages on their behalf. 

Canvas as Game Platform (optional/for discussion with Mike/Dan) 

As we have watched the development of the 3rd party ecosystem on 
Facebook.com, a clear pattern of usage has emerged. Canvas has become 
the default home for social games and Page tabs have become the default 
home for brand, contest, etc. apps. Moving forward, we are going to 
codify this within our product itself. Only new game apps will be able 
to leverage canvas (existing non-game apps are not effected). Non-games 
will continue to have access to page tabs. 

Platform 3.0 Rules of the Road 

As we work towards implementing the decisions that we made last year, 
which are now known as Platform 3.0, we need a common framework by 
which we can make decisions about what types of app to give access to 
Platform. This framework must address three key questions: what are the 
broad principles of our platform, how do these manifest in our 
products/policies and how do we communicate this to developers? This 
document answers these questions, constituting the Platform "rules of 
the road". 

Principles 

The fundamental principle that governs Platform usage is a simple 
concept: reciprocity. Reciprocity involves an equable value exchange 
between a 3rd party developer and Facebook. This value exchange 
involves one of the following from developers: high-quality experiences 
that FB users can use to tell great stories to their friends and family 
on FB and/or monetary value in the form of revenue sharing or direct 
payment. In return, Facebook offers a developers access to our Platform. 

When considering the implications of reciprocity it is important to 
note that a second order principle quickly emerges: competitive access. 
There are a small number of developers whom no amount of sharing to FB 
or monetary value can justify giving them access to Platform. These 
developers do not want to participate in the ecosystem we have created, 
but rather build their own ecosystem at the expense of our users, other 
developers and, of course, us. That is something that we will not 
allow. 
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Platform Services 


In order to outline how the above principles manifest in our 
products/policies, we need to identify the various parts of Platform. 
This is required because we have a disjoint set of product and policy 
constrains that apply to each of these different areas: 

App services: these are paid generic services (storage, compute, etc.) 
that apps may use to build the core foundation of their app. At present, 
we do not have an offering in this space, but we are close to closing 
an acquisition that adds these services. As such, in order to be 
complete and future-proof we will outline the rules associated with 
these types of services. 

Ads services: these are paid promotional services that enable 
developers to drive awareness and installations of their apps using 
News Feed and other paid channels. We have always had an advertising 
business the developers could leverage, but this is increasingly an 
area of focus for us with the transition to mobile. 

Identity services: these are the traditional identity/social services 
that we have provided to developers since 2007. These services enable 
developers to build personalized app experiences for people and enable 
these people to share aspects of those experiences back to Facebook. 
[todo: payments is here] 

Application 

The following outlines the application of the above principles to the 
various kinds of platform services. 

Strategic competitors: We maintain a small list of strategic 
competitors that Mark personally reviewed. Apps produced by the 
companies on this list are subject to a number of restrictions outlined 
below. Any usage beyond that specified is not permitted without Mark 
level sign-off. 

Ad services: All developers, save strategic competitors (above), may 
use our ads services. The reciprocity for these services is clear: 
money in exchange for new or re-engaged users. In terms of 
oversight/policy enforcement, we follow the standard ads creative 
review process. 

App services: All developers, save strategic competitors (above), may 
use our app services. The reciprocity for these services is clear: 
money in exchange for CPU, data storage and network bandwidth. In terms 
of oversight/policy enforcement, we will reactive handle any strategic 
competitors that we discover using these services. 
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Identity services: this set of services is the subject of much of the 
rules of the road. This is due to the fact that we have a variety of 
mechanisms for value exchange. 

All developers, including strategic competitors (above), may use the 
Login and Social Plugin features available within identity services. We 
permit this because we wish to see our core login service and basic 
sharing services used by users in any app, creating an equitable 
relationship with the all., including competitive, developers. To this 
end, we make these features available to developers with out app review. 

The use of identity services, beyond Login and Social Plugins, is 
subject to app review. We review the apps usage of our APIs to 
determine if they are adhering to our principles. In particular, we 
look at the quality of the app's user experience and if there existing 
some equitable value exchange. 

During app review, we determine the quality of the app by using the app 
and comparing the experience to our quality guidelines [link]. Apps 
that do not meet our quality bar are rejected. 

During app review, we examine the APIs that the app uses in order to 
determine what the appropriate level of reciprocity. The guideline for 
this review is "take data, give data". The review tool is built to help 
with this assessment in that for every read API used by the app, we 
flag if the app has also implemented Action importers. Using this tool, 
as well as an examination of the user experience itself; we can 
determine if the app is reciprocating. If they are not, the app is a 
"data leach" and will be rejected. 

Open Issues 

There are a number of different fields like birthday, hometown, etc. 
that apps can request and there is no way for them to write back 
anything. We can do a couple of things: create an API to set this info 
(maybe not a bad idea for identity growth?), limit these data fields to 
just canvas apps (the value exchange is time on site and maybe 
payments), pull these fields, something else? 

How do we think about the baseline level of value exchange of canvas 
apps due to time on site? Is that enough to forgo the "take data, give 
data" mandate for non-payment games/apps? 

If you are offering real/world goods for sale on your web site or 
mobile app, in order to use identity services, you must use Facebook 
Wallet (Payments 3.0)? 

Registration Plugin 

Need to talk to the field about not selling FB platform as part of an 
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ads deal (this is where we are seeing non-games canvas use) 

Group Management APIs? Event APIs? 

Todo/Notes 

Read 

Login (uid, name, profile pic., small # of core fields) - anyone can get 
this. No a priori review. 

User Data - requires user_* permissions. Ability to ask for those 
user_* permissions requires unified review. 

Friend List - Requires unifed review. If you access the friend list, 
you must conform with Social Reciprocity, as defined above. 

Friend Data - we're removing this (removing friend_* permissions) 

Core Facebook Features (News Feed API, Inbox API, Full Search API, 
etc.) - requires unified review. Generally only available with a 
business deal, generally limited to Facebook replacement apps. 

Write 

Share Dialog - anyone can use 

Open Graph (defining actions, using the API) - requires unified review 
Other Write/Management APIs (events, groups, etc.) - requires unified 
review. Generally requires a business deal, only available to Facebook 
replacement apps. 

Distribution 

Bookmarks - limited to canvas apps + mobile games. Requires unified 
review. 

Requests - limited to canvas apps + mobile games. Requires unified 
review. 

Notifications - limited to canvas apps + mobile games. Requires 
unified review. 

App Center + Search - limited to apps that have gone through unified 
review. 

Messaging (Invitations) - will require unified review. Available to 
anyone who abides by our rules (does not spam the channel). 

Reciprocity language: "Facebook Platform provides an extensive set of 
APIs that allow users to bring their data with them to your application. 
If you use any APIs beyond the basic login APIs, then you must also 
allow users to bring their data from your app back to Facebook by 
implementing the Action Importer spec." 
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EXHIBIT 44 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 


Dan Rose 


Sent: Thursday, January 24, 2013 12:21 PM 

To: Mike Vernal; Justin Osofsky; Mark Zuckerberg; Kevin Systrom; Douglas Purdy; Dan 

Rose 

Subject: Message summary [id.406139916141381] 


Justin Osofsky: 

>Twitter launched Vine today which lets you shoot multiple short video segments to make one single, 6-second video. 
As part of their NUX, you can find friends via FB. Unless anyone raises objections, we will shut down their friends API 
access today. 

> 

>We've prepared reactive PR, and I will let Jana know our decision. 

Mark Zuckerberg: 

>Yup, go for it. 


l 
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EXHIBIT 45 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 

Sent: 

To: 

Subject: 


Mike Vernal 

Tuesday, October 30, 2012 11:56 AM 
Open Graph PMs + EMs 

Re: [Open Graph PMs + EMs] Uploaded 2012_10_26 Platform data model v5.pptx 


Mike Vernal c o mmented on h is post i n Open Gra p h PMs + EMs. 


Mike Vernal 

HI,rather. 



11:56am Oct 30 


Comment History 


Mike Vernal 



11:55am Oct 30 


In terms of plans / execution - we need to finalize our strategy and then come up with an 
execution plan. I expect this will take 3-4 months, and will likely consume lots of cycles in 
H2. 



Mike Vernal 


11:55am Oct 30 


On Data Reciprocity - in practice I think this will be one of those rights that we reserv e. We'll 
publish a spec for an API that you have to implement to integrate with us, we'll have POPS 
review, but we'll pay closest attention to strategic partners where we want to make sure the 
value exchange is reciprocal. 



On Invitations Pricing - we need to sort this out. 

Vladimir Fedorov 11:37am Oct 30 

Are there any dates as far as the change is concerned ? I agree with the direction but there is a 
ton of details as far as execution goes. 



Greg Schechter 


10:22am Oct 30 


Two initial thoughts/questions: 


- seems like #3 (Data Reciprocity) is going to require a new level of subjective evaluation of 
apps that our platform ops folks will need to step up to — evaluating whether the reciprocity 
Ul/action importers are sufficiently reciprocal. 


- probably already being considered, but the pricing structure of invites to non-TOS'd friends 
will be very critical to adoption of this. Too high and apps just won't do it and we don't get 
viral app growth. Too low and we don't solve the problem. And since apps are very different 
in their LTV calculations of a user, it almost seems like this ideal pricing point is going to 
vary per app (at least up to a ceiling where we're making enough money that we're happy to 
cap it for that app). Could get very tricky. 



Alex Himel 

Ok, think I'm wrong on the friend connections. 


10:10am Oct 30 


View All Comments 


Original Post 



Mike Vernal 


9:43am Oct 30 


As many of you know , we've been having a series of conversations w / Mark for months 
about the Platform Business Model. 
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To give you an update on where we are — we feel pretty confident about the business model 
on the distribution / advertising side. Basically : 

- We want every one to be able to publish back to Facebook / contribute to the graph 

- We will organically rank content based on value to users and to Facebook (both 
engagement and revenue value) 

- Developers can pay us to value their value (i.e., they can boost content) 

There are lots of details to work out here (we need to update the feed ranking model to have a 
variable value for clicks, including negative value), but we feel pretty good on this front. 

Longer term, I think our distribution business model evolves into the overall OG model I 
described below. 

Most of the open questions have centered on the read side of platform. Specifically - why do 
we let apps access all this data today? A few possible justifications: 

- Because it's a valuable standalone business (the solution we're trying to find) 

- Because it' a loss-leader for the distribution business model (a hypothesis we're trying to 
prove) 

- Because it's a social good for the world (we think apps should be social) 

On Canvas we didn't have to ask ourselves these hard questions, because getting someone to 
build an app on canvas accrued a bunch of value. On Mobile, we need to ask ourselves these 
hard questions. Why let someone like Pinterest or Path read all of our data, create a separate 
standalone app, and then never use our paid distribution to compensate us? 

There have been a few important decisions we've already made (or tentatively made) that I 
wanted folks to be aware of: 

1/ We're going to dramatically reduce the data we expose via the Read API. In particular: 

- We are going to change friends.get to only return friends that are also using the app 

- We are going to introduce a paid invitations product that let users invite other users to their 
app 

- We are going to remove the ability to grant friend data via GDP. When a user TOSes an 
app, they can grant access to their own data. Since friends.get will only return other TOSed 
users' data, that means we no longer need the friend* permissions. 

- We are going to remove/whitelist access to the Stream APIs and Search APIs (and 
potentially other APIs that might leak the friend graph, like reading all notifications or the 
inbox) 

2/ We are going to limit the ability for competitive networks to use our platform without a 
formal deal in place. 

3/ We are going to require that all platform partners agree to data reciprocity. If you access a 
certain type of data (e g., music listens), you must allow the user to publish back that same 
kind of data. Users must be able to easily turn this on both within your own app as well as 
from Facebook (via action importers). 

Sorry for the long note, but wanted to make sure people had context on where the 
conversations currently are. I think this has a pretty big impact on some of our work around 
Notifications, Invitations, and Mobile SDKs in particular, so I'm going to follow-up w/ a 
smaller note to Gareth Davis, Bruce Rogers, Vladimir Fedorov, Charles Jolley, Eddie O'Neil, 
and Greg Schechter. 
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Please comment below / link if you have questions, 

r x ' 2012_10_26 Platform data model v5.pptx 
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EXHIBIT 48 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 

Sheryl Sandberg 

Sent: 

Monday, November 19, 2012 1:16 PM 

To: 

Mark Zuckerberg; Sam Lessin; Mike Vernal; Douglas Purdy; Javier Olivan; Alex Schultz; 
Ed Baker; Chris Cox; Mike Schroepfer; Dan Rose; Chris Daniels; David Ebersman; 
Vladimir Fedorov; Cory Ondrejka; Greg Badros 

Subject: 

RE: Platform Model Thoughts 


I think the observation that we are trying to maximize sharing on facebook, not just sharing in the world, is a critical 
one. I like full reciprocity and this is the heart of why. 


From: Mark Zuckerberg 

Sent: Monday, November 19, 2012 2:54 AM 

To: Sam Lessin; Mike Vernal; Douglas Purdy; Javier Olivan; Alex Schultz; Ed Baker; Chris Cox; Mike Schroepfer; Dan 
Rose; Chris Daniels; Sheryl Sandberg; David Ebersman; Vladimir Fedorov; Cory Ondrejka; Greg Badros 
Subject: Platform Model Thoughts 

After thinking about platform business model for a long time, 1 wanted to send out a note explaining 
where I’m leaning on this. This isn't final and we'll have a chance to discuss this in person before we 
decide this for sure, but since this is complex, 1 wanted to write out my thoughts. This is long, but 
hopefully helpful. 

The quick summary is that I think we should go with full reciprocity and access to app friends for no 
charge. Full reciprocity means that apps are required to give any user who connects to FB a prominent 
option to share all of their social content within that service (ie all content that is visible to more than a 
few people, but excluding 1:1 or small group messages) back to Facebook. In addition to this, in the 
future, I also think we should develop a premium service for things like instant personalization and 
coefficient, but that can be separate from this next release of platform. A lot more details and context 
below. 

First, to answer the question of what we should do, the very first question 1 developed an opinion on 
was what we should be optimizing for. There’s a clear tension between platform ubiquity and charging, 
so it's important to first fully explore what we're trying to get out of platform. 

The answer I came to is that we're trying to enable people to share everything they want, and to do it on 
Facebook. Sometimes the best way to enable people to share something is to have a developer build a 
special purpose app or network for that type of content and to make that app social by having Facebook 
plug into it. However, that may be good for the world but it's not good for us unless people also share 
back to Facebook and that content increases the value of our network. So ultimately, 1 think the 
puipose of platform — even the read side — is to increase sharing back into Facebook. 

If we do this well, we should be able to unlock much more sharing in the world and on Facebook 
through a constellation of apps than we could ever build experiences for ourselves. We should be able 
to solve the audience problem partially by giving people different audiences in different apps and 
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linking them all together on Facebook. The current state of the world supports that more social apps 
enables sharing, so the biggest challenge for us is to link them all together. 

This makes it somewhat clearer that we want platform to be ubiquitous and to strongly encourage 
sharing back to Facebook, but it's not yet definitively clear that having full reciprocity and no charge is 
optimal. 

For one thing, it's conceivable that we'd get more net sharing overall and more net sharing into 
Facebook if we didn't have a reciprocity mandate. This would be true if many developers dropped out 
over the reciprocity mandate. The reason I don't think they will is that almost no developers will even 
be giving us the majority of their data since many of their users won't log in with Facebook and many 
of those who do won't choose to share it back to Facebook. Assuming for a heavily FB-dependent app 
each of those is 50% participation, then only 25% of the data is shared to Facebook. As long as apps 
always have a sustainable advantage over Facebook, most will participate. For more sensitive 
companies like Amazon and Yelp that value their reviews a lot more, way fewer than 50% of their 
users will connect to Facebook, so this will represent a tiny portion of their reviews and social data. My 
guess is that they should still rationally want to connect with Facebook at these levels, but if they don't 
then that probably means they're competitive with us and we're better off not letting them integrate with 
us anyway. This all makes me think full reciprocity is the way to go. 

For charging, the question is whether we could charge and still achieve ubiquity. Theoretically, if we 
could do that, it would be better to get ubiquity and get paid. My sense is there may be some price we 
could charge that wouldn't interfere with ubiquity, but this price wouldn't be enough to make us real 
money. Conversely, we could probably make real money if we were willing to sacrifice ubiquity, but 
that doesn't seem like the right trade here. After looking at all the numbers for a while, I'm coming 
around to the perspective that the write side of platform is a much bigger opportunity for us and we 
should focus the vast majority of our monetization effort on that and not this. 

The last question is whether we should include app friends (ie the user's friends who are also using this 
app). Ultimately, it seems like this data is what developers want most and if we pulled this out of the 
package then most of the value proposition falls apart. This is especially true if we require full 
reciprocity without offering our most valuable data. 

So that's essentially how I got to thinking we should do full reciprocity with app friends and no charge. 
There's some more nuance to this opinion though: 

First, in any model, I'm assuming we enforce our policies against competitors much more strongly. The 
good news about full reciprocity is that for bigger social companies we might otherwise be worried 
about, if they're enabling their users to push all of their social content back into Facebook then we're 
probably fine with them. However, for folks like WeChat, we need to enforce a lot sooner. 

Second, if we're limiting friends to app friends, we need to make sure we build the appropriate 
distribution tools that developers want to invite the rest of the user's friends. We keep saying that 
theoretically this is part of the write side platform and it’s a premium feature, and those things may be 
true, but I think we need to build them and make sure they're ready when we roll this out or else we're 
just taking away functionality without replacing it with something better. It seems like we need some 
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way to fast app switch to the FB app to show a dialog on our side that lets you select which of your 
friends you want to invite to an app. We need to make sure this experience actually is possible to build 
and make as good as we want, especially on iOS where we're more constrained. We also need to figure 
out how we're going to charge for it. I want to make sure this is explicitly tied to pulling non-app 
friends out of friends.get. 

Third, there's the data that suggests that if we share app friends only, then most apps will only get fewer 
than 10 friends from each person. If this is the case, then we may want to consider including coefficient 
ranking for those app friends for free — or at least the top 5-10 app friends. This doesn't seem like much 
leakage and could encourage more people to use our tools by differentiation our product further from 
anything else that's out there. 

Fourth, for products like Ansible and Newsstand, it will be veiy important to enable people to import 
their feeds of content from other apps into Facebook. That is, we'd be pulling those people's friends' 
data from those apps — eg your friends' pins on Pinterest to make a Pinterest section for you in 
Newsstand or include the pin images on your Ansible lock/home. Since this is going to be an important 
upcoming push, we need to consider whether it's still the right thing to remove our own stream, get API 
if we're requiring full reciprocity. I still want to remove it, but if the spirit is full reciprocity, it may just 
be difficult to refuse access to the app that are pushing streams into us. The good news is that those 
services aren't the ones we're typically worried about, so we'd still get to prevent almost all troublesome 
apps from having it. The bad news is this would prevent us from really deprecating this. I haven't 
thought through this fully and need to think about it some more. 

Fifth, not charging still means people will overuse and abuse our APIs and waste money for us, so I 
still think we should implement some kind of program where you have to pay if you use too many of 
our resources. That said, the goal of this won't be to charge for actual usage so we can build a less 
precise system of for monitoring than the full accounting systems we would have had to have built for 
the other system we discussed. What I'm assuming we'll do here is have a few basic thresholds of API 
usage and once you pass a threshold you either need to pay us some fixed amount to get to the next 
threshold or you get rate limited at the lower thr eshold. One basic implementation of this could be to 
have a few different fees for developers, with basic starting at $100 and then having levels at $10k, 

$lm, $10m, etc. This should be relatively simple, achieve the goal of controlling costs and make us 
some money if we want. 

Finally, I want to discuss the premium read services for a bit. 

One of the big ideas I took away from our discussions was Ed Baker's framing that every business 
wants growth, engagement and monetization. I like this framing because it explains what the read side 
of platform is — it increases engagement, or more specifically, it takes a user and turns them into a 
more engaged user through adding real identity and social connections to them. This is real value and 
it's different from anything else we do. We have ads and some organic distribution for driving growth, 
the read side of platform for driving engagement and the ad network and payments for driving 
monetization. We'll offer the full stack of services. 

Flow our premium read services add value is pretty clear — through simply eliminating friction. Our 
free services let you get basic info, app friends and let you pay to get access to a dialog to invite more 
friends. Developers can always get these critical flows to perform better if they have more of the data 
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and more control though. Through instant personalization, they can encourage a person to sign in more 
effectively and will therefore convert more unregistered users to ones with real identity and friends. 
Through coefficient and full friends list, they can upsell a person to invite their friends much more 
effectively throughout their app as well. I'd estimate that these two things alone would increase 
conversion by -20-30% for developers. That means they should be willing to pay us roughly 20-30% 
of the value of each user who signs up. That's a big deal because engagement is very valuable. 

I have a specific proposal for how to get started with this and it's that we should work with mobile 
games. The feedback we're getting from almost eveiy other type of developer is they don't know how 
to value our services or really much of their engagement at all. But game developers generally hack 
this and have a better sense. They would certainly be willing to try it out in new games and they'd be 
able to figure out how well it worked. Once it works for most game developers, then we can start 
letting other developers in as well. 

Working with game developers has a few other nice properties. It means doing something nice for our 
game developers first and making them feel valued. It's fairly natural to offer IP on mobile since we 
already offer it to them on canvas. This could also be an important part of helping us transition our 
canvas business onto mobile if it effectively lets us take a 20-30% cut of the value of FB-connected 
users. 

On pricing, there are a couple of ways I could see this working. First, we could charge based on the 
value our ads auction computes for each user. I'm still fairly confident that's the most efficient way to 
charge if we can't just take a straight rev share. That said, the second choice, since this is just games, is 
to actually figure out how to just take a straight revenue share. This might be possible in conjunction 
with some sort of publisher model for games that I know the team is already thinking about. 

This all said, while I'd love to build this premium engagement model as quickly as possible, there’s 
definitely more low hanging fruit on the growth/distribution side that almost all developers will be able 
to use if we build out correctly. So we should probably prioritize that before premium engagement. 

We also need to first prioritize all the tools required to make these policies work, including making it 
so developers can actually share eveiything social in their apps back to Facebook if we’re requiring 
them to offer that option, the premium invite channel that will replace access to non-app friends, etc. 

Overall, I feel good about this direction. The purpose of platform is to tie the universe of all the social 
apps together so we can enable a lot more sharing and still remain the central social hub. I think this 
finds the right balance between ubiquity, reciprocity and profit. 

Again, this isn't final but I wanted to let you all know where I'm leaning. I'm looking forward to 
discussing when I'm back after Thanksgiving. 
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US mobile apps (iPhone) 


US iPhone App Reach, Aug 2012 - Mar 2013 (source: Onavo) 


Facebook - FB Messenger 

Instagram - Snapchat 

Twitter - 




% Reach, 

Mar. 

Rank 

Facebook 

72.6% 

+0.6 

1 

— 

Instagram 

34.0% 

+1.7 

3 

— 

Twitter 

27.2% 

+0.1 

6 

— 

FB Msgr 

13.7% 

+0.2 

15 

— 

Snapchat 

13.2% 

+1.6 

16 

+4 

Pinterest 

11.3% 

+0.2 

20 

+1 

WhatsApp 

8.6% 

+0.3 

30 

— 

Tumblr 

5.9% 

+0.4 

43 

+3 

foursquare 

5.0% 

+0.2 

57 

+1 

Vine 

3.9% 

+1.2 

71 

+25 

Google+ 

2.9% 

-0.2 

97 

-4 

Path 

1.0% 

+0.1 

243 

+22 



source: 

Onavo 
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US emerging mobile apps 


Vine: #1 overall /#1 social networking in US iTunes store 






Path: #9 overall / #2 social networking in US iTunes store 



source: AppAnnie 
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% reach 


US mobile messenger apps (iPhone) 


US iPhone App Reach, Aug 2012 - Mar 2013 (source: Onavo) 

March % Reach 

Skype 17.1% 

FB Messenger 13.7% 
WhatsApp 8.6% 

Viber 5.3% 

Kik 4.7% 

Voxer 3.8% 

Tango 3.5% 

GroupMe 2.4% 

Line 1.4% 

KakaoTalk 1.2% 

Message Me 0.5% 

Aug Sep Oct Nov Dec Jan Feb Mar 

source: Onavo; *Nielsen 


FB Messenger — Kik —*— Voxer - 

WhatsApp - Skype ~~~— 

Tango ... Viber 
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WhatsApp message sends 


Mobile messages per day by service 






£**•> 




2010 


2012 


2013 


Message sends/dav 

WhatsApp 8.2 billion 

Facebook 3.5 billion 

(mobile) 

Facebook 11.5 billion 

(mobile + 

web) 


HIGHLY CONFIDENTIAL 


FB-01367816 















India mobile apps (Android) 
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Dashboards 


Web industry data with user actions: 

https://our.intern.facebook.com/intern/data/portal/qem/industrv/overview 


Mobile ad-network data: https://clients.onavo.com (email for login) 
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US mobile apps (iPhone only) 


US iPhone App Reach, Aug 2012 - Feb 2013 (source: Onavo) 


Facebook - Facebook Messenger 

Instagram - Snapchat 

Twitter - 



February % Reach 


Facebook 

72.0% 

pts) 

(-0.5 

Instagram 

32.3% 

pts) 

(+0.3 

Twitter 

27.1% 

pts) 

(+0.1 

FB Messenger 

13.5% 

pts) 

(-0.1 

Snapchat 

11.6% 

pts) 

(+0.2 

Pinterest 

10.6% i 

[+0.1 pts) 

WhatsApp 

8.3% 

(+0.0 pts) 

foursquare 

4.8% 

(-0.0 pts) 

Google+ 

3.1% 

(N/A) 

Vine 

2.W rce (l$!? V0 


HIGHLY CONFIDENTIAL 


FB-0137 0642 





ENGAGEMENT <AVG USAGE DAYS/MONTH) 
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Snapchat app-store ranks 

United Kingdom: #1 Photo/Video; #5 Overall 



New Zealand: #1 Photo/Video; #5 Overall 



source: AppAnnie 
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Global web data dashboard 


https://our.intern.facebook.com/intern/data/portal/gem/industry/over 

view 
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UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



Login v4 (+ Platform 
changes) 

Update: 1/27/2014 
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Speaker Notes for Slide 1 


[theme] User Trust 

1/ Login v4 [permission x-out] 

2/ Login review 

[theme] Developers 
1/Versioned APIs 

2/Commit to 2yr stability for core Login, Sharing, Payments, Ads APIs and 
SDKs [iOS, Android, JS, PHP] 

3/ Bug fix SLA [UBN, hi-pri] 

4/Sticks 

= remove friend data APIs 

= remove APIs for News Feed, Timeline, Notifications, Inbox, managing 
Friend Lists 

= opaque user IDs for all apps 
= non-app friends only available by approval 
5/ Carrots 

= Social Context API [e.g. facepile - answers questions like "which 
friends are connected to Batman via which edge types”?] 

6/API deprecations [mostly dead products] 

= Checkins 
= Locations 
= Pokes 

= Subscribers / Subscribedto 
= Ouestions 

= Instant Personalization 
= Start Now 

7/API calls w/o access tokens [going to try this, might not be possible] 

8/ for games on canvas that use credits 
8.1/ Invites API [for custom MFS] 

8.2/Access to all friends for cross app promotion 

9/Other 

9.1/ Pivot the developer docs around Facebook Sharing as a product [sounds 
like this launched Tuesday] 
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Goals 

1. Increase User Trust 

1. Give people control of info they share [permission x-out] 

2. Increase quality of FB integrations in apps [Login Review] 

3. Minimize surprise [policy + friends model changes] 

2. Increase Developer Trust 

1. Versioned APIs 

2. Stabilize core APIs [2 year stability per Platform version + bug fix SLA] 

3. Protect the Graph 

1. Make it difficult to connect graphs between apps [opaque IDs] 

2. Limit data available to apps [remove friend APIs, privatize high-value 
APIs] 
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API Privatizations 


• Available via whitelist / contract 

• News Feed 

• Timeline 

• Inbox / messaging 

• Notifications 

• Requests 

• Friend List management 
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API Deprecations 


• Access to friend data [likes, photos, checkins, etc] 

• Questions, Subscriptions, Checkins, Pokes 

• Apps reading public posts for TOS’ed users 
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Affected Apps 



Total 

API callers 
[last 30d] 

1.4M 

Affected apps 

27,019 

Affected games 

3,111 

Affected Credits 
apps 

338 

Affected Ad 
Spenders 

89 

Affected Salesforce 
apps 

1,639 

Affected Salesforce 
games 

458 

Affected Salesforce 
non-games 

1,181 
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> 1,000 MAU 

> 10,000 MAU 

17K 

3,206 

7,744 

2,532 

1,475 

521 

315 

253 

82 

60 

1,262 

812 

375 

253 

887 

559 
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Key apps 



# of apps 

% requesting 
read_stream 

Mark’s friends 

31 

76% 

Sheryl’s friends 

66 

62% 

Generating TPV 

332 

51% 

Neko spenders 

831 

59% 

Noisy 

23 

82% 

TO / T1 partners 

160 

77% 


All on a list for pre-launch outreach 
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Model changes: highlights 

1. App scoped user IDs 

• Each partner has a unique ID space for users 

• Makes on-trivial to connect graphs across apps 

• Makes it possible to audit data leaks 

2. By default, apps can only read app friends 

• Common case for most apps 

• More difficult to grow Lulu, Circle, Klout, BranchOut, 
etc. 
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Speaker Notes for Slide 7 


Example: A TOS's w/ all friends, B TOS's w/o friends, if app doesn't know NAF, /A/friends didn't already include B 
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Affected Apps 


1. Difficult / impossible to build [without contract] 

• Alternate FB clients [Flipboard] 

2. Hard to grow 

• Messaging apps, contact sync apps, horoscope apps, 
birthday notifiers, gifting apps [ex: Wrapp] 

• Lulu, Klout, BranchOut 

3. Good apps 

• Venmo 
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Speaker Notes for Slide 8 


Wrapp: 
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Impact 


1. Canvas Games that use Credits: 

1. Adopt app scoped IDs 

2. Adopt new model for cross-app promotion 

3. Adopt new model for custom MFS 

4. Loss of ranking signals for friends 
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Impact 


2. Non-game apps / non-Canvas games 

1. Lose access to non-app friends 

2. Adopt app scoped IDs 

3. [harder to build] FB replacement clients [e.g. 

Flipboard] 

4. [harderto grow] Lulu, BranchOut, Klout, messaging/ 
contact sync / gifting / horoscope / birthday notification 
apps 

5. Casualties: Venmo, etc. 
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Speaker Notes for Slide 10 


Wrapp: 



HIGHLY CONFIDENTIAL 


FB-0135212 9 



Login v4 



• First screen 

• “App can’t post” 
text 

• Second screen 

• People have line 
item veto on 
permissions [except 

public profile] 
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Launch Timing 


• ~March 12: launch Login v4 

• April 30: developer event [f87] 

• Want 6-8 week separation between events 
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Questions 


1. Acceptable to deprecate Feed given broad impact? 

2. How quickly should apps lose access to Feed? 

3. Acceptable to make medium-term trade of Trust for 
Games? 

4. Commit to never removing basic Login from an app? 
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Appendix 
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Canvas Games using Credits 


1. Goal: minimize impact to Canvas games 

2. App-scoped IDs for new users 

3. Access to all friends for custom MFS [invites] 

4. Data 

1. ~900 financial entities [80% associated w/ multiple 
apps] 

2. ~2,300 active payment enabled apps [last 7d] 


HIGHLY CONFIDENTIAL 


FB-01352134 



Speaker Notes for Slide 15 


Changes from Vernal: 

1/ use a Social Context API for cross app promotion 
2 / 
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Non-game apps / non-Canvas 
games 


1. App scoped IDs for new users 

2. Apps limited to reading app friends 

3. Review 

1. [low bar] Access to API for tagging people 

2. [very high bar] Access to non-app friends 

1. Venmo: yes 

2. Lulu, Circle, BranchOut: no 
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Speaker Notes for Slide 16 

Investigate a functional Invites product 
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Developer Trust 


1. API versions [GET /v2.0/me/likes] 

2. Bug fix SLA 


UBN 

24h 

Hi-pri 

lOd 

Mid-pri 

30d 


2. Won’t publish TATs 

3. Near term, likely won’t meet mid-pri SLAs 
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Bug backlogs 


Team 

10/20/201 

3 

1/5/2014 

Growth 

% in SLA 

Ads 

80 

89 

+11% 

? 

API 

170 

218 

+28% 

? 

Devsite 

Content 

33 

51 

+55% 

? 

DevX 

38 

56 

+47% 

? 

Mobile 

Platform 

50 

49 

-2% 

? 

Platform Ul 

106 

152 

+43% 

? 
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Speaker Notes for Slide 18 


https://tableau.thefacebook.com/views/EngSLA/SLABacklog 

https://tableau.thefacebook.com/views/EngSLA/Dash 
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Other 


Core APIs 


User Fields 

id 

name 

first_name 

last_name 

picture 

gender 

locale 

age_range 

link 

timezone 

currency 

birthday 

email 


APIs 

GET /permissions j0S , Androjd , JS SDKs 

POST /feed _ PHPSDK 

POST /photos Login 


POST /videos Payments 

Like Button 
Ads 



HIGHLY CONFIDENTIAL 


FB-01352141 































Login Review 

1. Heavyweight review for high-value data [ex: photos] 

2. Lightweight review for fields on user object [ex: current 
city] 

3. Volume 

1. 110,000 apps need to go through Login review w/in 
6mo 

2. 1,800 new apps / day need review 


3. Curi 


apps /^av for OG 

4. TAT 

Good apps 

< 48h 


Others 

3-5 days 


/AC 


5. Tiering by classifier key to handling volume 
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App usage of friends 


App 

Use Case 

TripAd visor 

Show friend or fof reviews / star ratings 

Nike+ 

Compete with friends / friends leaderboard 

Spotify / Rdio / Stitcher 

See friend listening activity 

Sosh 

See friend places / activities / bookmarks 

Foursquare / Songkick 

Tag friends when publishing an OG story 

Foursquare / Shazam / 
Deezer/ Spotify / 

Mixcloud / EyeEm 

Find friends and subscribe to their activity feed 

Wrapp 

Buy a friend a gift on their birthday 

Tinder / HotOrNot 

Show mutual friends given a profile 

Vamos 

Event suggestions based on events popular among your friends 

Kickstarter 

Find + fund projects that friends are funding 

Bandisintown 

Concert recommendations based on friends. Find friends you can go to 
shows with. 

Strava 

Compete with friends. Show support for friends’ workouts. 

Waze 

See friends driving. Compete against friends for status. 

In stag ram 

Find + follow friends 

Delectable 

Tagging friends 

Venmo 

Send / receive money with friends 

In general 

Tagging non-app friends 
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User of high-value perms 


Permissions to 
privatize 

[won’t be publicly 
available] 

Total # of apps 
requesting these 
permissions / day 

[%games, %partners, 
%PMDs] 

# of apps requesting 
perm from > 1,000 users 
/ day 

[%games, %partners, 
%PMDs] 

Unique 

user+app pair 
perm 

impressions / day 


41,191 (54%, 1%, 
0.4%) 

384 (33%, 15%, 4%) 

a 074 471 

friends_* 

13,350 (14%, 3%, 
0.9%) 

482 (29%, 20%, 4%) 

7,013,87 

readjriailbox 

1987 (25%, 3%, 0.6%) 

246 (52%, 7%, 4%) 

1 , 495,538 

read_requests 

951 (11%, 5%, 1.2%) 

87 (72%, 12%, 2.3%) 

497407 

read_friendlists 

6304 (12%, 2%, 0.5%) 

179 (50%, 11%, 1%) 

1 , 344,731 

manage_notificatio 

ns 

983 (16%, 6%, 1%) 

93 (73%, 8.6%, 1%) 

442,259 

manage_friendlists 

661 (15.5%, 4.5%, 
0.6%) 

66 (90%, 4.5%, 0%) 

249,425 


A AAA / QO/_ O AO/. 4 A 0/_\ 

7ft /QC0/- A oo/_ n0/-\ 

OCO AVO 
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Data returned for NAF 


Redacted - Source Code 
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APIs returning friends 



Use Case 

ID 

Space 

API 

Can 

be 

cached 

# ofapps 

Notes 

1 

Login [no friends] 

A 

N/A 

Y 

10 A 6 

In the limit, we want all 
apps using Login 

2 

Login w/ friends 
[app friends + NAF] 

A 

/me/friends 

Y 

App Friends: 
10 A 5 

NAF: 10 A 2 

Currently used for cross 
app promotion 

3 

Tagging 

B 

/me/taggable_friends 

N 

10 A 4 

Requires approval 

H 

Social Context 

B 

/me/social_connection 

s 

N 

10 A 4 


5 

Invites 

A 

/me/inviteable_friends 

Y 

10 A 3 

Response sorted by 
likelihood of conversion 
Available only to Canvas 
games that use Credits 
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Social Context API 


• GET /{id}/social_connections 

• Callable if TOS’ed user grants user friends 

• Returns detailed data for AF. Summary data for NAF. 

• May end up with legal / policy requirement to disclose 
access to this data :\ 
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Example: Social Context API 


GET https://graph.facebook.com/ironman/social_connections? 
fields=name,action_type,friends.summary(1)& 
access token={user-token} 


Redacted - Source Code 


/ {user-id} supports 
mutual friends today 


HIGHLY CONFIDENTIAL 


FB-01352148 





Issues 


1. Complexity of migrating to opaque IDs 

2. Perception of omitting NAF from /me/friends 

3. Game adoption of Login v4 

4. Semantics of x’ing out user_friends 

5. Does not address Page API data leaks [major issue] 

6. Login v4 support for web / Canvas 

7. Documentation 
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New Constraints 

1. [policies] Login 

1. No infinite loops 

2. Additional password only if required, must be explained 

3. Cannot re-prompt for data available through FB using empty 
form 

2. [policies] user friends 

1. If apps can access NAF: for users that x-out friend 
permissions, apps cannot use data from FB to bootstrap 
social connections between users 

3. [pTOS] Once apps can read X% of the graph, they must talk to 
us. Akin to the MAU cap. 

4. Contract required to read NAF 
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Login v4 

1. Model for x’ing out user_friends 

1. Two choices 

[assume A TOS’s w/ friends. B TOS’s w/o friends.] 

1. If apps get app friends: B is never in A’s friend list 

2. If apps get all friends: B is in A’s friend list. Policy 
prevents apps from auto-wiring A <=> B [ex: auto- 
follow, TOS notifs] 

2. Users who revoke can be found in app’s search + followed 

3. Users who revoke cannot send Requests via Custom MFS 

4. For A: B.installed = true 

5.iOS Login Dialog disabled for v4+ 
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Klout Login Dialog 



Klout w® receive the following info: your public 
pro!©, friend 1st, email address, News Feed, 
birthday, work history, education history, 
current city and likes. 


:vn 




App Tarms P rsvacy Policy 
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Wrapp Login Dialog 
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Launch Tinning 

Mar June September 

2014 2014 2014 


Launch Login v4 1 1 

1. Announce app scoped IDs and app friend changes 

2. Start Login Review 

3. Start deprecation windows for friend_* / NF / TL / Notif / etc APIs 


3 months End read_stream + 

User NF/TL API 
deprecations 


6 months App IDs 

- App Friends 

End friend_* / other API deprecations 
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EXHIBIT 79 

UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 

Konstantinos Papamiltiadis 

Sent: 

Monday, September 23, 2013 7:24 AM 

To: 

Ime Archibong 

Subject: 

Re: What do you think? 

v0.6 



From: Ime Archibong 

Date: Friday, September 20, 2013 8:23 PM 
To: Konstantinos Papamiltiadis 
Subject: Re: What do you think? 

Some comments in the doc 


From: Konstantinos Papamiltiadis 
Date: Friday, September 20, 2013 9:58 AM 
To: Ime Archibong 
Subject: Re: What do you think? 

v0.4 with summaries 


From: Ime Archibong 

Date: Friday, September 20, 2013 5:03 PM 
To: Konstantinos Papamiltiadis 
Subject: Re: What do you think? 

That makes sense. Add 1-2 bullets for each. It's got to be concise language though. Take a cut at that. 


From: Konstantinos Papamiltiadis 
Date: Friday, September 20, 2013 8:59 AM 
To: Ime Archibong 
Subject: Re: What do you think? 

Good feedback, do you think I should add some "context" related to those apps below the screenshots? Maybe a brief 
explanation of what they do? 


From: Ime Archibong 

Date: Friday, September 20, 2013 4:43 PM 
To: Konstantinos Papamiltiadis 
Subject: Re: What do you think? 

Good rev. Its getting stronger. I've made a couple high level recommendations in here. Take another cut at it and then we'll 
do the detail/messaging polish. 
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From: Konstantinos Papamiltiadis 
Date: Friday, September 20, 2013 8:21 AM 
To: Ime Archibong 
Subject: Re: What do you think? 

Of course, I forgot we have this issue... attached as .ppt 


From: Ime Archibong 

Date: Friday, September 20, 2013 4:15 PM 
To: Konstantinos Papamiltiadis 
Subject: Re: What do you think? 

Thanks for sharing, KP. Look forward to going through it. 

Can you save this as a PPT and send over so that I can do some edits to send you? 
Ime 


From: Konstantinos Papamiltiadis 
Date: Friday, September 20, 2013 5:51 AM 
To: Ime Archibong 
Subject: Re: What do you think? 

Hello Ime, 

As a follow up to your feedback and the call with the DevOps folks, I went ahead and updated the slides. Attached. 

There are a few things we need to talk about, that I did not realize, that you may be aware of. 

Should we use our ltol on Monday to go through those? Do please (provided you have time), send me any further thoughts 
you may have on those in the meantime. 

Once you are happy I think we will need to share those with the following folks: 

1/ Allison when she is back from Jury duty as we need to review potential changes on the policies 
2/ Chris and Justin to address open questions 
3/ Sam, Vernal and Doug for final sign off 

Thanks a lot, 
kp 


From: Ime Archibong 

Date: Thursday, September 19, 2013 5:54 AM 
To: Konstantinos Papamiltiadis 
Subject: Re: What do you think? 

Ok. I'm quadruple booked at that time, so I'll sync up with you after if anything changes.:-) 


From: Konstantinos Papamiltiadis 

Date: Wednesday, September 18, 2013 9:44 PM 

To: Ime Archibong 

Subject: Re: What do you think? 
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Just did! I hope you can make it! 


On 19 Sep 2013, at 04:18, "Ime Archibong" wrote: 

And I'm happy to join tomorrow's mtg if I'm free. Feel free to fwd the invite. 


From: Konstantinos Papamiltiadis 

Date: Wednesday, September 18, 2013 10:06 AM 

To: Ime Archibong 

Subject: Re: What do you think? 

Hello Ime, 

I spent the best part of today thinking about the process as well as the requirements but the attached is still 
an early draft. 

Still, I wanted to get your initial thoughts as I was planning to use those slides when I talk to DevOps and 
Allison tomorrow morning (at 11am if you want to join) about this. 

Key points: 

1/ Find out what other apps like Refresh are out there that we don't want to share data with and figure out if 
they spend on NEKO 

* Communicate in one-go to all apps that don't spend that those permission will be revoked 

* Communicate to the rest that they need to spend on NEKO at least $ 250K a year to maintain access to the 
data 

2/ Review future submissions and reject/approve as per the requirements above 

3/ Update our policies if need be 

4/ Comms / PR plan if # of apps affected is significant 

Just fyi, we will be at an EMEA offsite tomorrow - but will be online late in the afternoon. 

Thanks a lot, 
kp 


From: Ime Archibong 

Date: Tuesday, September 17, 2013 9:57 PM 
To: Konstantinos Papamiltiadis 
Subject: Re: What do you think? 

Oh, just seeing this but sent a separate response. 

I'm ok with the outcome but let's just figure out how to do things elegantly. I don't think he denied option A. 
I think we should adjust that approach to being a bit more aggressive with our data restrictions, to protect 
our strategic goals. 

Great job. 


From: Konstantinos Papamiltiadis 
Date: Tuesday, September 17, 2013 1:40 PM 
To: Ime Archibong 
Subject: What do you think? 
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While I can't say mission accomplished (given Sam did not go for option A), I think overall it was a good half 
way solution. Would you agree? 

As for next steps, I will put a few thoughts together on: 

1/ How to make this elegantly 

2/ The specific requirements for our review team and SPDs to counter offer to developers 

Thanks for setting this one up, 
kp 
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EXHIBIT 80 

UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 

Simon Cross 

Sent: 

Thursday, September 05, 2013 12:33 PM 

To: 

Konstantinos Papamiltiadis; Ime Archibong; Jackie Chang 

Subject: 

Re: P3.0 Rollout Planning 


Id say for now, just list out the capabilities/Gks/Sitevars we want to audit - but don't actually do the audit - that's what we'll 
do in the hack. We need to build collective experience on how to review the access that's been granted, and how to make 
decisions about keep/kill/contract. 


This review cycle should include whats currently in Capabilities, as well as whitelists administered via Gks and Sitevars. I don't 
want us to have to go through this excise ever again. For example, we should appraise what Netflix (for example) has across all 
these three whitelisting mechanisms in one go. 



Simon Cross 
Product Partnerships 


From: Konstantinos Papamiltiadis 

Date: Thursday, September 5, 2013 11:05 AM 

To: Simon Cross , Ime Archibong , Jackie Chang 

Subject: Re: P3.0 Rollout Planning 

Awesome. I could try either of the following two options: 

1/ Identify capabilities that matter and find out which companies use them and audit those 
2/ Audit Tier 0 and 1 partners across all the capabilities 

From previous conversations with Marie adding the GKs into the Talent tool is still a few months out, so we may need to 
repeat the process then. 

Any thoughts/preferences mainly on either 1 or 2 above? 

Cheers, 

kp 


From: Simon Cross 

Date: Thursday, September 5, 2013 7:00 PM 

To: Konstantinos Papamiltiadis , Ime Archibong , Jackie Chang 

Subject: Re: P3.0 Rollout Planning 
Sure! 

The main thing is planning for the "Capabilities Cleanup". 
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As we discussed, probably the best way to do this is to attack it as a 2 day (?) hackathon. We should involve some guys from 
the scaled outreach team and the PMD team too, and possibly others who are still at the company who used to be involved in 
Partnerships. 

What we need to do to make this happen is the following: 

• Draw up a list of the Capabilities, the Gatekeepers and the non-capability sitevars that we want to include in the audit 
- perhaps tiering them by significance. 

• Draw up a list of the high-risk/threat companies (and their apps) that we want to audit - we should order these by 
MAU 

• Build a spreadsheet for use in the hack where we list out the apps, companies and capabilities we've audited, and out 
decision about any action we take. I think this comes down to 4 options: 

1. Keep access (and verify we have an agreement with them 

2. Revoke access 

3. Keep access, but need to get an extended Platform agreement with them 

4. Escalate (need someone else to make a call, or to provide more context) 

The first two bullets will be the place to start. 

Want to take a stab at that? 

We should also check with Marie about the scope of what the Talent tool covers, and if they have imminent plans to migrate 
whitelists currently controlled by Sitevars or Gatekeeper into this tool. 

S 


Simon Cross 
Product Partnerships 


From: Konstantinos Papamiltiadis 

Date: Thursday, September 5, 2013 10:47 AM 

To: Simon Cross , Ime Archibong , Jackie Chang 

Subject: Re: P3.0 Rollout Planning 

Hello Simon, 

Are there any actionable items after the meeting with Chris I could help with? 

Let me know. 

Cheers, 

kp 


From: Simon Cross 

Date: Wednesday, September 4, 2013 7:57 PM 

To: Konstantinos Papamiltiadis , Ime Archibong , Jackie Chang 

Subject: Re: P3.0 Rollout Planning 
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Feedback in line: 


From: Konstantinos Papamiltiadis 

Date: Wednesday, September 4, 2013 4:28 AM 

To: Simon Cross , Ime Archibong , Jackie Chang 

Subject: Re: P3.0 Rollout Planning 

This is SUPER, Simon. You nailed it. 

A few recommendation on minor issues: 

1/ Slide 2:1 think you are right to suggest that a full audit is a huge task with unclear value. I certainly agree with your 
recommendation, however I would recommend that we do a thorough audit on the apps that have been whitelisted for 
capabilities equivalent to the public APIs we will be deprecating, i.e apps that have been whitelisted for read_stream 
APIshould be audited the same way as those that request the read_stream permission. Same for friends_*, read_mailbox, etc. 
My take is that if we deprecated the permission, there is no point maintaining access to the capability all together. 

Agree we should review these - however, the capability will remain to give access features which are publicly deprecated, but 
available to whitelisted apps. 

2/ Slide 3: How did you come up with the Tiering & SLA here? My 2cents is that this is a bit confusing and I would stick to the 
classification outlined on Slide 4. 

This is actually the classification the PM team are using. They're separating partner APIs (titan api, auth.login) from the set of 
APIs you need to rebuild a Facebook client (FB in-house apps, BlackBerry, Windows Phone). The aim is to reduce the # of third 
party ’internal' apps and manage them more strongly. 

3/ Slide 4: Should we add a few examples next to the 4 categories, I.e Pre-enforce: Twitter, Standard: Amazon, Extension: 
Samsung TV, Exception: HTC 

Yep - done 

4/ Slide 5:1 am not sure about the revenue saved. Is this really a cost-cutting exercise? Removing access to all_friends lists 
seems more like a indirect way to drive NEKO adoption. 

Jackie and I discussed this - I think most people here have no idea of the cost we expend running these APIs or which apps 
cost use the most. I agree with Jackie that instrumenting this gives us a great line internally about the money we’re saving as 
well as cleaning up the platform. 

5/ Slide 7:1 think the XFN team should also include the TV and Mobile folks together with Games, 
sure 

6/ Slide 8: We need to make a recommendation on who can help us with the audit. Would that be dev ops? As per the 
discussion with Allison, they have no capacity to help us. Could we ask for Justin's help with the UO team? 

Agree we need help - not sure which team is best as it depends on how deep we decide to go, will leave as open question. 

I hope this feedback is useful. Thanks again for putting those together. 

Cheers, 

kp 


From: Simon Cross 

Date: Wednesday, September 4, 2013 3:28 AM 
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To: Ime Archibong 


, Jackie Chang 


, Konstantinos Papamiltiadis 

Subject: Re: P3.0 Rollout Planning 
Here's my draft deck for review tomorrow. 

Yes, its a little longer than hoped, but I feel it needs to standalone when passed around beyond Chris, assuming he's OK with 
this strategy. 

Feedback welcome, will try and incorporate ASAP 
S 


From: 

When: 2:00 PM - 2:30 PM September 4, 2013 
Subject: P3.0 Rollout Planning 

Location: [LON0042.05] Nemesis; [MPK0018.02N] Barbie & Ken (Reservable Seats 8 LCD/WB) 


Moving so Jackie can make it, and better for KP 
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EXHIBIT 83 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 

Bryan Hurren 

Sent: 

Monday, October 28, 2013 1:31 PM 

To: 

Ashley Rutledge; Jackie Chang 

Cc: 

Simon Cross; Sachin Monga; Eddie O'Neil 

Subject: 

Re: Follow up on Friends List + Messages API 


ILet me dig up the email. 1 may have sent it only to Sachin 


-Original message. 

From: Ashley Rutledge 

Date: 10/28/2013 1:23 PM (GMT-08:00) 

To: Jackie Chang 

Cc: Bryan Hurren ,Simon Cross Sachin Monga 

,Eddie O'Neil 

Subject: Re: Follow up on Friends List + Messages API 


Fli Jackie, 

Yes, I will communicate to the client and run point on execution. 

I have a meeting this Thursday at 9a est. Any chance 1 could have a draft of the doc prior? 

Thanks 

Ashley 


On 2013-10-28, at 4:09 PM, "Jackie Chang" wrote: 

+ Eddie 

@Bryan - can you take the lead on getting this agreement written up? 

@Eddie - Doug gave a pproval for for Royal Bank to use Titan API and they're now ready for 
launch. As a heads up, Bryan will take the lead in getting the agreement in place with RBC, but 
worth putting on your radar that there are now 2 partners with this whitelist api. 

@Sachin & Ashley - once Bryan get's the agreement, can you get your partner to sign the 
agreement and do not let them launch until they get the agreement back to us? 


From: Bryan Hurren 

Date: Friday, October 25, 2013 at 11:06 AM 

To: Simon Cross Ashley Rutledge Jackie 

Cc: Sachin Monga 

Subject: Re: Follow up on Friends List + Messages API 

Sachin and I were chatting on another trail, and I spoke to Eddie yesterday briefly. 
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Eddie's view is that this is a good use case, but would like to see the experience. 


From a PR perspective, the story is about the app, not the API, so the fact that it uses Titan isn't a big deal. 

From a legal perspective, they need an "Extended API agreement" (we used with Netflix) which governs use 
going forward and should provide us the freedom to make the changes that Simon mentions below (without 
being too explicit). One thing that's not clear to me: I'm not sure how Titan will interop with a hashed version 
of the FBID. 

Happy to help facilitate getting an agreement written up. Suzie and Frank were the BD and legal folks I 
worked with. 


bryan hurren | strategic partnerships | facebook | 

From: Simon Cross 

Date: Friday, October 25, 2013 at 10:56 AM 
To: Ashley Rutledge , Jackie Chang 

Cc: Sachin Monga Bryan Hurren 

Subject: Re: Follow up on Friends List + Messages API 

+ bryan who recently whitelisted Netflix for the messages API - he will have a better idea of what agreements 
we need to give them access to this API. 

S 


Simon Cross 
Product Partnerships 


From: Ashley Rutledge 
Date: Friday, October 25, 2013 8:56 AM 
To: Simon Cross Jackie Chang 

Cc: Sachin Monga 

Subject: Re: Follow up on Friends List + Messages API 
Hi Simon and Jackie! 

I mentioned to Sachin yesterday that I would like to speak via phone with Simon re: the potential contract 
needed. Jackie, please let me know if you would like to be involved. Note I have no issue suggesting this to 
the RBC clients, however want to be sure I understand what purpose it serves and what this will protect. 

Please be on the look out for a meeting maker... 

Thanks, 

Ashley 
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Ashley Rutledge 
Facebook 


From: Simon Cross 

Date: Wednesday, October 23, 2013 1:34 PM 
To: Jackie Chang 

Cc: Sachin Monga d 

Subject: Re: Follow up on Friends List + Messages API 

Hey sachin. 

Do we have a contract with them that covers the use of the messaging API? 

As that's already a private API it shouldn't be affected by psl2n. 

The big change you should quietly ensure they'll be ready to handle is the move to hashed uids. This means 
that once the migration is enabled, un-ToS'd users' ids will change. 

But the good news is that because of this change, we'll continue to return the users full friend list. The 
message API allows users to send messages to un-ToS'd friends today right? 

As Jackie says, we shouldn't give them a heads up that change is a-coming. 

Let's ensure we have a contact with them which sets us up to keep them on our whitelist post psl2n. 

S 

Sent from my iPhone 

On 23 Oct 2013, at 10:19, "Jackie Chang" wrote: 

+ Simon who's leading the efforts around this on our end 

Developers are allowed to develop under the current framework. We ask that no discussion 
of PS with partners until messaging is fully prepared, etc. 

When it comes time for PS, we'll figure out paths to unwind partners in a reasonable time, 
but because nothing is solidified yet, we can't guide anyone on what or what not to do. 

We'll just flag this integration with Simon as one of the apps we'll need to work closely with 
on providing a reasonable unwind path when it comes time. 

Hope that helps. Thanks! 


From: Sachin Monga 

Date: Tuesday, October 22, 2013 6:24 PM 
To: Jackie 

Cc: Ashley Rutledge 

Subject: Re: Follow up on Friends List + Messages API 
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Hey Jackie, 


We're getting closer to launch and the app is looking great. 


I saw Eddie's post 

wanted to follow up to make sure there were no red flags with respect to platform 
simplification for this app. 


As a reminder, they are using friends list + messages API to allow an authenticated user to 
send money to a friend (regardless of whether the friend is authenticated or not). 


Hope things are well. Let me know if there's anything we need to do here. 
Thanks - 


Sachin 


From: Jackie Chang 

Date: Thursday, August 22, 2013 7:19 AM 
To: Sachin Monga 

Subject: Re: Follow up on Friends List + Messages API 

Let's pause any action for now until we have internal discussions about this tomorrow. I 
should have better guidance for you Friday/next Monday. Don't be anxious - we'll do the 
right thing to take care of this. Thanks! 

From: Sachin Monga 

Date: Wednesday, August 21, 2013 7:11 PM 
To: Jackie 

Subject: Re: Follow up on Friends List + Messages API 
Hey Jackie - 

Do you have an estimated time frame on when we might have a better understanding of 
whether or not the Messages API will include the ability to access non-app friends? I'm a bit 
anxious about this given how close we are to launching and how much is on the line for the 
partnership. Any update (if we haven't figured it out even just an estimate on when we 
might) would be great. Also, if there is anything I can do to help (provide more info, etc.) 
please let me know. 

Thanks - 

Sachin 


From: Sachin Monga 

Date: Tuesday, August 20, 2013 11:34 AM 
To: Jackie Chang 

Subject: Re: Follow up on Friends List + Messages API 

Launching iPad on October 1, then iPhone in November. Also to clarify - it will be an update 
to their existing iOS app ( https://itunes.apple.com/ca/app/rbc-mobile/id407597290?mt=8 ). 
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They are not using our payments system. Banking in Canada is semi-regulated, and every 
bank banded together to create a system called Interac 

( http://en.wikipedia.ore/wiki/lnterac ). Interac powers the back end of all debit purchases 
and also allows anyone with a Canadian bank account to send money to anyone else with a 
Canadian bank account. Every bank has a function in their mobile app and website called 
"Interac eTransfer" that lets you send money to another person via their email address 
(powered by Interac). Their FB integration is simply allowing this transfer to happen over 
Facebook Messages as well. 


From: Jackie Chang 

Date: Tuesday, August 20, 2013 11:08 AM 
To: Sachin Monga 

Subject: Re: Follow up on Friends List + Messages API 
Also - when are they launching this? 

From: Jackie 

Date: Tuesday, August 20, 2013 11:03 AM 
To: Sachin Monga 

Subject: Re: Follow up on Friends List + Messages API 

Are they going to be on our payments system or are they just relaying on our channels? 
From: Sachin Monga 

Date: Tuesday, August 20, 2013 10:58 AM 
To: Jackie , Constantin Koumouzelis 

Cc: Ashley Rutledge , Neil Hiltz 

Subject: Re: Follow up on Friends List + Messages API 

Thanks for the quick response. Answers below: 

1. Correct, partner is RBC Royal Bank (RBC_payments group in the whitelist tool) and 
their AppIDs (dev, staging, prod) are 

here https://our.intern.facebook.com/intern/capabilities/group.php2group name= 

2. They did not sign an extended API agreement. Should they have? I didn't know 
about this -1 was following this 

doc: http s:// www.facebook.com/groups/42049414133254 0/d oc/421300334585254 

i 

3. Doug gave the approval. Permalink in 

group: https://www.facebook.com/groups/420494141332540/50040553334140Q/ 
and also attached a couple of email threads where he comments that it's a great 
use case. 

4. There is budget tied specifically to this app update (all mobile app install ads to 
existing RBC customers, via custom audiences). I believe it will be one of the biggest 
neko campaigns ever run in Canada (Ashley can comment with more details). 

Thanks again! 

Sachin 
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From: Jackie Chang 

Date: Tuesday, August 20, 2013 10:46 AM 

To: Sachin Monga , Constantin Koumouzelis 

Cc: Ashley Rutledge , Neil Hiltz 

Subject: Re: Follow up on Friends List + Messages API 

Sachin, thanks for the below details. What would really be helpful for us is if you can provide 
the below details first: 

1/ what's their app id? (Partner is RBC Royal Bank) 

2/ did they sign an extended api agreement when you whitelisted them for this api? 

3/ who internally gave you approval to extend them whitelist access? Can you send me 
email or permalink from the Platform Whitelist Approval group. 

4/ is there budget tied specifically to this integration? How much? 

We need the above info foremost and we understand the context below. Thanks! 

From: Sachin Monga 

Date: Tuesday, August 20, 2013 10:38 AM 
To: Jackie , Constantin Koumouzelis 

Cc: Ashley Rutledge . Neil Hiltz 

Subject: Follow up on Friends List + Messages API 

Hey Jackie & Constantin, 

Long time no talk, hope you guys are doing well. 

Wanted to follow up about on this 

thread https://www.facebook.com/eroups/platform.fyi/permalink/550920554956564/2com 
ment id-551335571581729&offset-0&tot al comments-8 about the upcoming Platform 3.0 
rollout. Overall, I'm really pumped about these changes and I think they definitely represent 
a positive direction for user trust. 

It seems like the main use case for an authenticated user to be able to access their entire list 
of friends (including non-app friends) is invites, so glad to see that we'll be creating a specific 
invite solution to meet this case. Another valid use case is messaging, although there are 
only a handful of partners who have access to the Messages API (as far as I know only 
Dropbox, RBC, and our own first party apps?). I want to see if I can work with you on 
managing this use case with the upcoming changes. My initial thinking is that the ability to 
access friends list can be coupled with the Messages API (and in this case, you can only 
access friends list for the purpose of messaging a friend as opposed to invites, etc.). I'm 
guessing the invite solution will be similar (only access friends list for the purpose of inviting 
them to the app in a safe manner). 

Without the ability to access non-app friends, the Messages API becomes drastically less 
useful. It will also be impossible to build P2P payments within the RBC app, which would 
have dire consequences for our partnership with them (each side has been invested in this 
since the beginning of the year, and there is a big financial commitment from them). They 
are the biggest bank in Canada, a top 20 global bank, and the Platform, Payments, and 
Messages teams are all really excited about this use case for its potential to (a) have the 
finserv industry re-think the role of Facebook in retail banking, and (b) act as a test case for 
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more compelling high signal 'transactions' over FB messages (sending money, sharing files, 
customer service with a business, etc.). 

The user flow of the app is attached (basic flow is a user authenticates, sees a list of their 
friends, chooses a friend, enters the $ amount, and hits send. Their friend receives a FB 
message with a link to claim the money). Besides icons and names, it's accurate and finalized 
and had been approved by Doug & the payments team a couple of months ago. 

We're a little anxious about this change - and hoping to see what I can do to help manage 
the transition. I'm actually in MPK this week if you want to catch up live... let me know. 

Also cc'd Ashley who leads the relationship with RBC and Neil who is the vertical solutions 
lead on Financial Services. 

Thanks - 

Sachin 
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EXHIBIT 84 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 


Konstantinos Papamiltiadis 


Sent: Friday, February 06, 2015 10:55 AM 

To: 

Subject: Re: Changes to FB API April 2015 - Hashed Anon All Friends API 


Hello 

Can you please share the exact request you make to get this error message? 

Thanks a lot, 
kp 


From: 3adoo.com > 

Date: Friday, February 6, 2015 at 5:59 PM 
To: Konstantinos Papamiltiadis 

Cc: badoo.com >, badoo.com >, Julien Codorniou 

Subject: Re: Changes to FB API April 2015 - Hashed Anon All Friends API 

Well, we did a lot of calls in a different way, but here is an error we get: 

{"error":{"message":"Unsupported get request. Please read the Graph API documentation at 
https:\A/ developers.facebook.com \/docs\/graph-api"."type":"GraphMethodException"."code":100}) 


On 6 Feb 2015, at 14:01, Konstantinos Papamiltiadis wrote: 

Hello 

Badoo App ID has definitely been whitelisted... According to out logs you have made already 100 calls against 
this API. 

Are you following the guidelines from the docs (specifying an app secret, etc)? 

Thanks a lot, 
kp 

From: badoo.com > 

Date: 1 hursday, February 5, 2015 at 11:20 AM 
To: Konstantinos Papamiltiadis 

Cc: 3adoo.com >, 3adoo.com >, 

Julien Codorniou 

Subject: Re: Changes to FB API April 2015 - Hashed Anon All Friends API 
Hi, 
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Developers are looking into it and they coming back with report of API returning error. 

Also according to doc we will not be able to show name/profile pic and even people who granted permissions 
will be hashed? 

Because your original explanation was about existing users will be opened? 

Anyway if for "hashed" we can only say: you have 2 levels of connections it will be kind of not trustworthy for 
the end users. 


On 5 Feb 2015, at 08:46, Konstantinos Papamiltiadis wrote: 

Hello All, 

We have now whitelisted Badoo (App ID:: ), HotorNot (App 

ID: ) and Bumble (App ID: ) for the Hashed Friends API 

that was shipped late last night. 

The docs are here: https://developers.facebook.com/docs/graph- 

api/reference/v2.2/user/hashed friends - only visible to people listed in the roles section of 
your app. 

Please start testing this API as soon as can - and feel free to give feedback or ask any 
questions you have. 

We sincerely hope that this API along with the All Mutual Friends 
API https://developers.facebook.com/docs/graph- 

api/reference/v2.2/user.context/all mu tu al fr i ends means you have everything you need to 
upgrade to Graph API v2.x. 

Thanks a lot, 
konstantinos 

From: Konstantinos Papamiltiadis 
Date: Friday, January 23, 2015 at 11:02 AM 
To: badoo.com >.! 

badpo.com> 

Cc: badoo.com >. Julien Codorniou 

Subject: Re: Changes to FB API April 2015 - Hashed Anon All Friends API 

Hello and 

We have now approval from our internal stakeholders to move ahead with a new API - 
working name Hashed Anon All Friends API. The new API as well as the relevant docs will be 
ready next week. 

How would this API work... For each of the FB logged in users, the API will return: 

FBIDs: App friends that logged in before your migration to V2: 

App Scoped IDs: App friends that logged in after your migration to V2: 

Anonymous one-way hashed IDs: Non-app friends 

This API will hopefully let you understand some of the structure of the graph in order to 
determine which non-app friends to recommend to a given user, and thus which pairs of 
users to call the All Mutual Friends API on behalf of. These hashed Ids will be in an entirely 
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new namespace (l.e. Different to anything you have today), its purely for matching 2nd and 
3rd order mutual friends etc. 

The following example may help... 

<7A763973-555B-4DCB-BB50-2CBC18D49B38.png> 

For ill, we'd emit hashed IDs for: u8, u5, u4 & app scoped ID for u3 
For u2, we'd emit hashed IDs for: u6 , u4 & app scoped ID for u3 and u7 
For u7, we'd emit hashed IDs for: u5 & app scoped ID for u2 

Thus, the app could determine that ul and u2 are related: 

* via u3 (2nd order via app-user) 

* via u4 (2nd order via non-app user) 

* u5 and u7 (3rd order). 


Note, the relationship via u6 would not be known as u6 is not friends with >=2 
app-users. 


Based on the above, the number of API calls you will need to make against the 
Mutual Friends API will be drastically reduced as well. 

Let me know if that would work. 

kp 


From: badoo.com > 

Date: Thursday, September 18, 2014 at 11:24 AM 

To: Konstantinos Papamiltiadis 

Cc: bad o o . com> 

Subject: Re: Changes to FB API April 2015 

Hi KP 

We are talking about the complete friends list and no other friends data (other than the 
profile picture of the friend). 
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Thanks, we look forward to hearing. 


On 18 Sep 2014, at 11:24, Konstantinos Papamiltiadis wrote: 


Hello 

With regards to point (a) below, can I please clarify that you are talking about the complete 
friends list and not any other friends data, such as friends_photos, that you request right 
now, even though there is no obvious use of the data? 

As per my earlier note, I have already flagged this with the leadership in the product team 
and we are certainly thinking about both (a) and (b) below - with the exception of friends_* 
data. 

I shall be able to send you an update once we have a better idea of the plan here, 
kp 


From: 3adoo.com > 

Date: Tuesday, September 16, 2014 at 9:03 PM 

To: Konstantinos Papamiltiadis 

Cc: ba d o o . c o m> 

Subject: Changes to FB API April 2015 

Hi KP 

Hope you're well. 

I know you've had a chat with about the changes coming up to the FB API. I was 

planning to send an email along the lines of the draft below to the platform team, and 
specifically Sean Ryan (VP of Platform Partnerships) and possibly Nicola Medelsohn Head of 
EMEA. 

Could I ask a favour of you? Firstly, do you think they're the right people, secondly, do you 
think the email below is along the right lines? Any feedback greatly appreciated! 

Best 


Dear Facebook Platform Team 

We write to you with regard to the v2.0 API which will be in effect from April 2015. 

We understand, and commend the steps being taken by Facebook to tighten security around 
the use of user data, and indeed limit opportunity for abuse of user friend lists. However, we 
have been compelled to write to you to explain the hugely detrimental effect that removing 
friend permissions will cause to our hugely popular (and profitable) applications Badoo and 
Hot or Not. 
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The friends data we receive from users is integral to our product (and indeed a key reason 
for building Facebook verification into our apps). Without the ability to access and use social 
graphs, applications become not just generic, but the "social" aspect is removed. Specifically 
in relation to our applications, the reason that Friends data is crucial to our product are: 

a. User engagement is increased by users being able to see shared/mutual friends. This is 
because for applications like ours, where users are meeting and chatting, a huge element of 
trust, and engagement is created by showing users shared friends. To reiterate, within this 
process, we don't abuse any data, we simply show users a name and photo of the friend and 
demonstrate the connection. 

b. We use friend lists to enable users to 'recommend' friends to other friends. This is an 
exciting feature of our applications, and enhances the user experience, again, by bringing in, 
and supporting the element of trust on the application, but also as a fun engagement 
feature. 

c. ln order to reduce and limit fraudulent/Spam/Scam on our applications, we also analyse 
friend lists by cross referencing against our maintained lists of known fraudsters, in order to 
verify the safety of accounts. This improves the user experience and improves the safety of 
our site. 

In our view it is a misperception that friend permissions are used to add virality of an 
application/spam users. They are vital to the integrity, trust and engagement of a product, 
and it is for these reasons alone that we use the friend social graph in our application. We 
would therefore be very grateful if you could reconsider how the proposed changes will be 
applied to our applications, and whether there are any assurances we can give to you that 
would support a change in your decision. 

We look forward to hearing from you, and would be happy to set up a call/arrange a 
meeting to discuss in more detail. 

Kind regards 


Director & General Counsel 


badoo.com 


<badoo logo small.gif> 

Badoo Trading Limited is a limited company registered in England and Wales under CRN 7540255 with its registered office 
atMedia Village, 131-151 Great Titchfield Street, London. W1W 5BB 


This email is confidential and is intended for the addressee only If you have received if in error, you are on notice of its status. 
Please notify us by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purpose 
or disclose its content to any other person. 


cbadoo logo small.gif> 
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EXHIBIT 85 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 

§)hootsuite.com> 

Sent: 

Wednesday, April 29, 2015 5:44 PM 

To: 

Monica Tsang 

Cc: 

Reagan Williams; Simon Cross; : Marty Henningsgard; Ashley Moore; Evan 

Chen; Trevor Longman; Sachin Monga; Phil Lam; Gregory Gunn; Chris Richardson; 
Harshdeep Singh; Konstantinos Papamiltiadis; Allison Hendrix; Tiffany Jung; Chris Gora 

Subject: 

Re: Hootsuite: 2.0 next steps 


Great, cheers! 


On Wed, Apr 29, 2015 at 5:06 PM, Monica Tsang wrote: 

Hi. 

Attached is the updated agreement with valid Ids (please double check) and removed the duplicate one. 

Thanks, 

Monica Tsang 

From: 

Date: Wednesday, April 29, 2015 at 7:18 PM 
To: Reagan Williams 

Cc: Simon Cross, Monica Tsang, , Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, 

Sachin Monga, Phil Lam, Gregory Gunn, Chris Richardson, Harshdeep Singh, Konstantinos Papamiltiadis, 

Allison Hendrix, Tiffany Jung, Chris Gora 
Subject: Re: Hootsuite: 2.0 next steps 

Hi Reagan, one more thing - just tried to correct the Hootsuite Production ID (should be ) & remove the 

duplication, but the document is locked for editing. 

Can you please update on your end? 


On Wed, Apr 29, 2015 at 4:00 PM, (5) hootsuite.com > wrote: 

Thanks Reagan. Our follow up notes: 

1) Good catch - these is a '1' missing from the end of the ID + they're just duplicates of eachother. Will make sure this is 
properly updated before returning. 

2) Discussed your summary with Product, and yes, that's also our understanding of how mapping will behave across our 
different environments. 
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Manager, Strategic Alliances | Hootsuite 
@costyou 


Find Hootsuite online: 



We are hiring in a big way! Apply now 


This email is being sent on behalf of Hootsuite Media, Inc . If you are no longer interested in receiving emails from Hootsuite, please unsubscribe here . 

Hootsuite Media Inc., 5 East 8th Avenue. 

Vancouver, BC, V5T 1R6. 

On Wed, Apr 29, 2015 at 3:39 PM, Reagan Williams wrote: 


Two quick items: 

1) We just noticed that the first two appids listed on line #1 and #2 are invalid/incorrect in Exhibit A. Please make sure those 2 
lines are updated on the final contract. 

2) Simon and I were talking and we want to confirm we all understand functionality with your team on how the mapping will 
behave, and how it will interact between environments: 

Hootsuite Prod will be able to map appids from it's own app to NG and Actiance. 

Hootsuite Staging will be able to map appids from it's own app to NG and Actiance. 

Hootsuite Dev will be able to map appids from it's own app to NG and Actiance. 

Lastly, a user's id will be different between the Hootsuite prod, staging, and dev environments as per our standard app- 
scoped-id behavior. 

Reagan 


From: 

Date: Wednesday, April 29, 2015 at 3:27 PM 
To: Simon Cross 

Cc: Monica Tsang, Reagan Williams, , Marty Henningsgard, Ashley Moore, Evan Chen, Trevor 

Longman, Sachin Monga, Phil Lam, Gregory Gunn, Chris Richardson, Harshdeep Singh, Konstantinos 
Papamiltiadis, Allison Hendrix, Tiffany Jung, Chris Gora 
Subject: Re: Hootsuite: 2.0 next steps 

Will get this turned around as soon as possible. 

Thank you for all the hard work on this! 


On Wed, Apr 29, 2015 at 3:23 PM, Simon Cross wrote: 

+ Reagan 
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From: Monica Tsang 

Date: Tuesday, April 28, 2015 at 6:43 PM 

To: 

Cc: Simon Cross, , Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, Sachin Monga, 

Phil Lam, Gregory Gunn, Chris Richardson, Harshdeep Singh, Konstantinos Papamiltiadis, Allison Hendrix, 
Tiffany Jung, Chris Gora 
Subject: Re: Hootsuite: 2.0 next steps 

Hi 

Updated agreement. See attached. 

Thanks, 

Monica ‘Tsang 

From: 

Date: Tuesday, April 28, 2015 at 2:23 PM 
To: Monica Tsang 

Cc: Simon Cross, , Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, Sachin Monga, 

Phil Lam, Gregory Gunn, Chris Richardson, Harshdeep Singh, Konstantinos Papamiltiadis, Allison Hendrix, 
Tiffany Jung, Chris Gora 
Subject: Re: Hootsuite: 2.0 next steps 

Hi Monica, 

Checked in with the technical team working on the Mapping API and they mentioned that we'll need whitelisting for each of 
our application environments, including dev + staging (listed below) for our continuous deployment process. Can we please 
add them to the whitelist + agreement? 

Staging - 
Dev - 


Otherwise, Legal has reviewed and everything else looks great! 



Manager, Strategic Alliances | Hootsuite 
@costyou 


Find Hootsuite online: 



We are hiring in a big way! Apply now 


This email is being sent on behalf of Hootsuite Media. Inc . If you are no longer interested in receiving emails from Hootsuite, please unsubscribe here . 

Hootsuite Media Inc., 5 East 8th Avenue. 

Vancouver, BC, V5T 1R6. 


On Mon, Apr 27, 2015 at 10:37 PM, 


ahootsuite.com> wrote: 
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Great, thanks Monica! 


Our team will review & get back to you as soon as possible. 


On Mon, Apr 27, 2015 at 8:15 PM, Monica Tsang wrote: 

Hi 

Our legal team approved the changes you proposed, see attached for latest contract. 

Once signed and returned, we will be able to provide you with the mapping API. Let me know if you have any questions. 
Thanks, 

Monica Tsang 

From: 

Date: Monday, April 20, 2015 at 6:25 PM 
To: Monica Tsang 

Cc: Simon Cross, , Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, Sachin Monga, 

Phil Lam, Gregory Gunn, Chris Richardson, Harshdeep Singh, Konstantinos Papamiltiadis, Allison Hendrix, 
Tiffany Jung, Chris Gora 
Subject: Re: Hootsuite: 2.0 next steps 

That is a big help, thank you Monica! 

Our legal team is reviewing and we'll get back to you on this as soon as possible. 



Manager, Strategic Alliances | Hootsuite 
@costyou 


Find Hootsuite online: 



We are hiring in a big way! Apply now 


This email is being sent on behalf of Hootsuite Media. Inc . If you are no longer interested in receiving emails from Hootsuite, please unsubscribe here . 

Hootsuite Media Inc.. 5 East 8th Avenue. 

Vancouver. BC. V5T 1R6. 


On Mon, Apr 20, 2015 at 2:44 PM, Monica Tsang wrote: 

Hi 

We did a little bit of research, and found the AppIDs. I've attached the legal agreement. Please double check that the 
information is correct. 
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Feel free to reach out if you have any questions. 


Thanks, 

Monica Tsang 
From: Monica Tsang 

Date: Monday, April 20, 2015 at 12:57 PM 
To: 

Cc: Simon Cross, , Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, Sachin Monga, 

Phil Lam, Gregory Gunn, Chris Richardson, Harshdeep Singh, Konstantinos Papamiltiadis, Allison Hendrix, 
Tiffany Jung, Chris Gora 
Subject: Re: Hootsuite: 2.0 next steps 

Hi 

Just wanted to let you know the legal agreement is ready. I can send it over to you once you provide me with the app Ids. 
Thanks, 

Monica Tsang 


From: Monica Tsang 

Date: Friday, April 17, 2015 at 4:41 PM 

To: 

Subject: Re: Hootsuite: 2.0 next steps 

Thanks, keep me posted once you have the IDs. Thanks! 

Have a great weekend! 

Sent from my iPhone 

On Apr 17, 2015, at 4:00 PM, 5>hootsuite.com > wrote: 

Hi Monica - still waiting on app IDs from Actiance + NexGate. 

Our main contacts, plus my Enterprise Compliance BD team are OOO for SlFMA's major finance conference. 
In the meantime, below is the rest of the information you need: 

Name: 

Title: VP, Product 
Developer: Hootsuite Media Inc. 

Address: 

Hootsuite appID: 


On Wed, Apr 15, 2015 at 10:55 PM, Monica Tsang wrote: 

Hey 
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We're almost therewith the legal agreement, we're hoping end of week (latest next Monday). In the 
meantime, can I get the following information from you? 

Name: <Person who will be signing the contract at Hootsuite> 

Title: <Title of person named above> 

Developer: <Company full names 
Address:<Company address> 

Hootsuite appID: <ID that will use the API> 

Actiance appID: 

NexGate appID: 


Thanks, 

Monica Tsang 


From: Monica Tsang 

Date: Thursday, April 9, 2015 at 10:06 PM 

To: 

Subject: Re: Hootsuite: 2.0 next steps 
Hi 

Thanks for letting me know about 2/. I'll make sure that the legal agreement is drafted to reflect this change. 
Slight change in timeline, I got a chance to sync up with our Legal team this afternoon, and it may take a little 
longer than next week to get the agreement to you as it's more complex then I initially thought. We are still 
aiming for next week, but wanted to set expectations with you that it may take until the week after (l.e. 
Week of 4/20). 

Let me know if this is going to be an issue. 

Thanks, 

Monica Tsang 

From: 

Date: Thursday, April 9, 2015 at 6:25 PM 
To: Monica Tsang 

Cc: Simon Cross, Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, 

Sachin Monga, Phil Lam, Gregory Gunn, Chris Richardson, Harshdeep Singh, Konstantinos 
Papamiltiadis, Allison Hendrix, Tiffany Jung, Chris Gora 
Subject: Re: Hootsuite: 2.0 next steps 

Thanks for following up Monica. 

We'll hang tight while Simon is OOO but in the meantime, I've got a few more notes from my team to share: 

1/ Manage_Groups - given the anticipated scope of work required to integrate this permission, our dev 
team will need access by the end of next week to make the 2.0 deadline. 

21 User ID Mapping - based on most recent conversations with Global Relay, they don't actually 
support e-discovery and do not need to be included in the legal agreement. This change has been 
reflected in the overview of compliance use cases & data-flows we shared earlier. 

6 


CONFIDENTIAL 


FB-00031250 






Manager, Strategic Alliances | Hootsuite 
@costyou 


Find Hootsuite online: | ^]| fW] | [xj l ^]| 0 

We are hiring in a big way! Apply now 

This email is being sent on behalf of Hootsuite Media. Inc . If you are no longer interested in receiving emails from Hootsuite, please unsubscribe here . 

Hootsuite Media Inc., 5 East 8th Avenue. 

Vancouver, BC, V5T 1R6 

On Thu, Apr 9, 2015 at 11:19 AM, Monica Tsang wrote: 

Hi 

1/ Simon would be the best person to answer this question 

2/ Work in progress. Hoping to have this over to you next week. Thanks for your patience. 

Thanks, 

Monica ‘Tsang 


From: 

Date: Thursday, April 9, 2015 at 1:34 AM 
To: Monica Tsang 

Cc: Simon Cross, , Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, 

Sachin Monga, Phil Lam, Gregory Gunn, Chris Richardson, Harshdeep Singh, Konstantinos 
Papamiltiadis, Allison Hendrix, Tiffany Jung, Chris Gora 
Subject: Re: Hootsuite: 2.0 next steps 

Hi Monica & Simon, wanted to check in on a few items required to inform client messaging + development 
efforts: 

1/ Manage_Groups 

• Still on track to release this week? 

• Can you please clarify whether the core functionality listed below will be supported by the new 
permission? This info is needed for the communications (in-product, email, help article, etc) we’re 
preparing to notify users of upcoming changes: 

1. View content in a groups that the user is an admin of 

2. Interact with content (like, comment, etc) in a group that the user is an admin of 

3. Publish messages to all groups a user belongs to, even if they are not an admin 

2/ User ID Mapping Agreement 

• Any updates on timing you can share? 

Thank you! 
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On Mon, Apr 6, 2015 at 3:05 PM, fflhootsuite.com > wrote: 

Hi Monica, we've confirmed that what you identified is the source of the discrepancies on deprecation 
notices we've been observing. 


Thank you for the support! 



Manager, Strategic Alliances 
@costyou 


Hootsuite 


Find Hootsuite online: 
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Hootsuite Media Inc., 5 East 8th Avenue. 
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On Sun, Apr 5, 2015 at 5:59 PM hootsuite.com > wrote: 

Thanks Monica. Our dev team will look into this asap. 
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On Sun, Apr 5, 2015 at 5:22 PM, Monica Tsang • wrote: 

Hi 

I took a quick look, and your app - has enabled the default admin to v2.0 feature which can 

explain the behaviors you are seeing. 

To turn it off, simply to go your app's dashboard > Settings > Migrations and set "Default Admins, Developers 
and Testers to Graph API v2.0" to OFF. Note - this toggle gets automatically reset to ON periodically, the next 
time it will be toggled to ON is this Thursday April 9th, 2015. So you will need to take these steps again on 
that day. FYI - We send out Dev Alerts on the day where this gets automatically re-enabled, so make sure you 
check your app inbox. 
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Hope this resolves your issue. 


Thanks, 

Monica Tsang 

From: 

Date: Sunday, April 5, 2015 at 5:13 PM 
To: Monica Tsang 

Cc: Simon Cross, , Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, 

Sachin Monga, Phil Lam, Gregory Gunn, Chris Richardson, Harshdeep Singh, Konstantinos 
Papamiltiadis, Allison Hendrix, Tiffany Jung, Chris Gora 

Subject: Re: Hootsuite: 2.0 next steps 

Thanks for prompt follow up Monica! I've forwarded to the right folks on our technical team to check. 


On Sunday, April 5, 2015, Monica Tsang wrote: 

Hi, 

Simon is on vacation this week, so I hope I can help you resolve this issue. 

Can you double check whether your app has enabled the default admin to v2.0 feature? See more info 
here: https://developers.facebook.eom/docs/apps/upgrading#defaulting20 

Thanks, 

Monica Tsang 


From: 

Date: Sunday, April 5, 2015 at 4:18 PM 
To: Simon Cross 

Cc: , Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, Sachin 

Monga, Phil Lam, Gregory Gunn, Chris Richardson, Harshdeep Singh, Konstantinos 
Papamiltiadis, Allison Hendrix, Monica Tsang, Tiffany Jung, Chris Gora 
Subject: Re: Hootsuite: 2.0 next steps 

Hi Simon - we've seen occasional deprecation notices being returned for Facebook Searches. In debugging this 
development, we haven't been able to find any commonalities between the users seeing it (Graph 1 token vs Graph 2 
token, or user account vs developer account). 

As such, my we're wondering if Facebook is rolling out a broad deprecation for this endpoint ahead of the Graph 2 
changeover on April 30th? If so, if there is any info on this development that you can share with us? And if not, do you 
know what else may be causing these irregularities? 

We're planning on starting our phased technical rollout of API changes timed against controlled in-product & direct client 
messaging, but this development (+ the manage_groups releasej impacts plans so we're hoping to have more clarity 
w/in the next few days. 

Thanks Simon, really appreciate the updates. 
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wrote: 


On Tue, Mar 31, 2015 at 7:49 PM, Simon Cross 
Hey -thanks for checking in! 

We're actively planning the manage groups permission - details to share soon, hopefully next week. 

Same situation with the user ID mapping. Will let you know when we have any progress to share. Feel free to 
keep pinging me for updates. 

S 

From: 

Date: Tuesday, March 31, 2015 at 5:17 PM 

To: 

Cc: Simon Cross, Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, Sachin 
Monga, Phil Lam, Gregory Gunn, Chris Richardson, Harshdeep Singh, Konstantinos 
Papamiltiadis, Allison Hendrix, Monica Tsang, Tiffany Jung, Chris Gora 
Subject: Re: Hootsuite: 2.0 next steps 

Hi Simon, 

Now that F8 has passed I wanted to check in and see if there’s any updated timelines/info you can share on the 
manage_groups permission release or a draft of the User ID Mapping agreement. 

Thanks, and hope you had some time over the weekend to relax & celebrate a successful F8. 



Manager, Strategic Alliances | Hootsuite 
@costyou 
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On Fri, Mar 27, 2015 at 6:11 PM, @hootsuite.com> wrote: 

+( & who head up legal at Hootsuite. 
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Hi Simon - here is an overview of Hootsuite's communication with clients and partners to support pre & post¬ 
review compliance use cases. Please let us know if you have any Qs. 

Also - your team did an amazing job with F8. Couldn't have been more impressed with the location, content 
or production, and I heard only heard that sentiment echoed across other FB Marketing Partners. 

All the best, 
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On Sun, Mar 22, 2015 at 3:25 PM, (®hootsuite.com> wrote: 

Hi Simon, 

Agreed-getting a better understanding of context will definitely help when we move towards a firm 
agreement. To get there, Hootsuite will be summarizing everything in a doc this week, to be more easily 
shared. 

In the meantime, I can answer your question. We haven't finalized the integration specification yet, but we 
are definitely leaning towards translating App-Scoped IDs into the Partner value at application borders. This 
will be a cleaner solution, allowing each app to deal w/ IDs in their own format, and allowing us to minimize 
the number of modules that have access to the ID translation API. 

Thanks, 

On Sun, Mar 22, 2015 at 2:55 PM, Simon Cross wrote: 

Hey , yes, this should be enough. 

Architecturally, we're still deciding the details of how this mapping would work in detail - for example: do 
you sent a HS ID to NexGate which they have the ability to resolve into their namespace, or do you translate 
to a NexGate ID before sending the data to them. This architecture depends very much on how data flows 
between you and your partners, and if any further data exchange happens between them. 

Thanks for this - as I say, we're really on hold here until after F8, but I really appreciate this context. 

S 


From: 

Date: Sunday, March 22, 2015 at 2:15 PM 
To: Simon Cross 
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Cc: , Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, Sachin 

Monga, Phil Lam, Gregory Gunn, Chris Richardson, Harshdeep Singh, Konstantinos 
Papamiltiadis, Allison Hendrix, Monica Tsang 

Subject: Re: Hootsuite: 2.0 next steps 

Hello Simon, 

Data-flow diagrams might be a bit of overkill for these scenarios. Perhaps a simple text sequence might be 
easier: 

Pre-Review (NexGate) 

1. In Hootsuite, a message is authored and user clicks Send Now or Schedule 

2. Message, with Facebook Profile ID, is sent to NexGate 

3. In NexGate, message body is compared against compliance policy configured for that Facebook ID 

4. Result (success or failure with context) is returned to Hootsuite 

5. In Hootsuite, message is then either sent/scheduled on success, or a notification of failure is sent to the 
user on failure 

Post-Review (Global Relay & Actiance) 

1. In Hootsuite, a message is authored and user clicks Send Now or Schedule 

2. Message is sent by Hootsuite to the selected Facebook Profiles/Pages 

3. In Hoosuite, a digest of that message is prepared, including information on the user who published the 
message and native network ID (Facebook ID) 

4. Hootsuite sends this message digest to either Global Relay or Actiance for archive 

5. Some time later, during an e-Discovery investigation, the Facebook ID associated with the message is used 
to determine the actual Facebook account published to 

In some cases, a partner like NexGate might have additional partnerships with archiving providers like Global 
Relay. In that scenario, the data would be further sent from NG over to Global Relay for archiving. NexGate 
would need to resolve the App-Scoped IDs in that scenario. A client might elect to use this workflow instead 
of directly archiving from Hootsuite (or directly archiving via just Global Relay) for any number of reasons 
(existing workflows, different network support, etc). It's important to note that these configurations are 
entirely up to the client, and are implemented at their direction. 

Our proposed changes for App-Scoped IDs would involve Hootsuite using the ID mapping API to resolve the 
Hootsuite App-Scoped ID into the appropriate third party App-Scoped ID prior to sending information to our 
partners. Thus, the message would arrive at our partners APIs with their own App-Scoped ID in use. 


On Sat, Mar 21, 2015 at 11:15 AM, Simon Cross wrote: 

Hey, 

We don't have any problems with pre-review. And we don't have any problems with post-review, as long as 
you're meeting our bar for use of the permissions: l.e. Making visible use of them to enhance the user's 
experience - and you've now been approved for us for all the permissions you should need to power these 
experiences - although as you know we can't grant read_stream, user_groups and read_mailbox for the 
post-review use case as per our previous conversations. There's no additional contracts needed here. 
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Re user-1 D sharing between you and your partners, I do understand the timing issues, but out legal and 
partnerships teams are swamped with F8 so we're unlikely to make progress here until after that. 

Yes - it would be super-valuable if you guys can share some info - perhaps data-flow diagrams that will help 
our legal and privacy teams understand how data flows between you and your various partners. Its also 
important for us to understand any ways data could flow between you and multiple compliance partners 
(NexGate + Global Relay etc) 

As you know sharing user ID-level data between companies is against our policies, so granting exceptions 
under a contract requires us to really understand the systems in use here to ensure people's information is 
being properly protected. That said, I'm confident we can find a way to support your needs here. 

Could you guys get some details to us towards the end of next week? Thanks for offering to put this together. 

Best, 

Simon 


From: 

Date: Friday, March 20, 2015 at 5:20 PM 
To: Simon Cross 

Cc: Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, Sachin Monga, Phil Lam, 
Gregory Gunn, Chris Richardson, John Hallett, Harshdeep Singh, Konstantinos Papamiltiadis, 
Allison Hendrix 

Subject: Re: Hootsuite: 2.0 next steps 

Great, thank you for the follow up here Simon. 

Also understand your position on providing written approval of use cases. But, since we’ve only verbally 
reviewed everything and timelines on legal turnaround will be very tight - would it be helpful for our team 
to share a brief overview of Hootsuite’s pre & post-review use cases and our communication flows with 
clients + partners for reference while drafting the agreement? 

I just want to ensure your team is fully supported & that legal review goes as quickly + smoothly as 
possible. 

Hope all is going well w/ F8! 



Manager, Strategic Alliances 
@costyou 


Hootsuite 
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Hootsuite Media Inc., 5 East 8th Avenue. 
Vancouver, BC, V5T 1R6. 


On Wed, Mar 18, 2015 at 5:29 PM, Simon Cross wrote: 

Following up again here, just to confirm you guys have now been approved for the following permissions: 

• userposts(1451957028376236) 

• manage_pages(170547803119479) 

• readjriendlists (204220799727469) 

• read_page_mailboxes (206012479551763) 

• publish_actions (268176543326971) 

• user_photos (350208451771320) 

• user_status (420181021422482) 

• user_events (468518859900119) 

• user_about_me (672343712783148) 


Thanks, 

Simon 


From: Simon Cross 

Date: Tuesday, March 17, 2015 at 7:10 PM 

To: 

Cc: Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, Sachin Monga, Phil Lam, 
Gregory Gunn, Chris Richardson, John Hallett, Harshdeep Singh, Konstantinos Papamiltiadis, 
Allison Hendrix 

Subject: Re: Hootsuite: 2.0 next steps 

Hey 

I sadly can't provide any written guarantees that your use of our platform, or the use cases you outline, are 
within our policies. But I can say you're likely to be approved via Login Review for user_posts for these 
purposes as long as the data obtained via this permission is visibly used to enhance the experience of people 
who log into your app, and you follow our normal data-retention policies. 

As to user ID sharing between you and your compliance partners, that is currently against our policies, but we 
hope to work up an agreement to cover this - though this is likely to be after F8. 

That said, as the API vl.O deprecation deadline is approaching, I suggest you begin the engineering and 
product work to migrate away from read_stream, user_groups and the Post Search API so as to avoid any 
disruption on April 30th. 

Thanks, 

S 

From: 

Date: Tuesday, March 17, 2015 at 2:56 PM 
To: Simon Cross 

Cc: Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, Sachin Monga, Phil Lam, 
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, Harshdeep Singh, Konstantinos Papamiltiadis 


Gregory Gunn, Chris Richardson, 

Subject: Re: Hootsuite: 2.0 next steps 

Hi Simon, our technical + partner management teams needs to move forwards on this soon. Any update? 

Thank you! 



Manager, Strategic Alliances | Hootsuite 
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On Thu, Mar 12, 2015 at 9:06 PM, (®hootsuite.com> wrote: 

Very helpful, thank you for the thorough follow up Simon! 

With that timeline on legal, looks like we’ll need to run development and legal work on User ID Mapping in 
parallel to make the migration deadline. 

Though before Hootsuite and our compliance partners' technical teams can begin investing the 
engineering resources, they’ll need explicit assurance that Facebook approves of the use cases we 
outlined (pre & post-review + archiving). Can you provide email confirmation of that approval for Hootsuite 
& our partners? 

If so, Greg will take this solution back to technical execs and see if that provides enough confidence for 
engineering work to move forwards. 
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On Thu, Mar 12, 2015 at 9:37 AM, Simon Cross wrote: 

Hey 
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User ID Mapping API: 


1/ Yes, any solution will involve the Business Mapping API so you should start scoping out that work now. 

2/ This will be a very manual process. The contract will likely list all the app Ids in play, and the mapping 
won't be provisioned until the contract has been signed by you and each of your partners. 

3/ We're working through this now, targeting 3-4 weeks. As you'd imagine, F8 is our #1 priority right now and 
that's taking up much of our legal and partnerships team's bandwidth 

New permissions: 

1/ user_posts is now live! You can start using this now and add it to your Login Review submission. This 
permission has been auto granted to anyone who already has read_stream l.e most of your existing users. 
This means, assuming you get approved via Login Review, your existing users won't have to re-loging and 
grant this perms for your app to retain Timeline access. You should update all your login flows to request this 
permission as you move away from read_stream. 

2/ manage_groups: We're still working on this and will share details in the next few weeks. Its likely that 
people will have to manually grant this permission in order for apps to retain access to some groups - as 
theres no other way for us to know which groups a user wants to grant the app access to without them 
explicitly saying so. 

Hope that helps. 

Simon 


From: 

Date: Wednesday, March 11, 2015 at 4:04 PM 

To: Simon Cross, Marty Henningsgard, Ashley Moore, Evan Chen, Trevor Longman, Sachin 
Monga 

Cc: Gregory Gunn, Chris Richardson, 

Subject: Hootsuite: 2.0 next steps 

Hi Simon and team, 

Thanks for a great call on Monday and to keep the momentum, I wanted to follow up on the 2.0 migration 
issues we’ve been discussing: 

Bi-directional Business Mapping API > given the complexity of implementing this solution - in particular 
coordinating engineering work across multiple compliance partners and drafting a legal agreement - we 
need to move fast on this. 

• Technical - will the solution be based of the Business Mapping API ? And if so, what will the 
registration process look like for Hootsuite & our compliance partners? 

• Legal - is there an approximate timeline on the drafted legal agreement? 

New Permissions (user_post & manage_groups) 

• User Migration - if an existing user has authenticated vl, what will the migration to net new 
permissions look like? Will these be granted automatically, or will a user need to re-auth? 

• User_post & manage_groups - update on release timelines for these permissions? 

Best, 


16 


CONFIDENTIAL 


FB-00031260 




Manager, Strategic Alliances | Hootsuite 
@costyou 


Find Hootsuite online: 



We are hiring in a big way! Apply now 


This email is being sent on behalf of Hootsuite Media. Inc . If you are no longer interested in receiving emails from Hootsuite, please u nsubscribe here . 

Hootsuite Media Inc., 5 East 8th Avenue. 

Vancouver, BC, V5T 1R6 



Senior Product Manager | Hootsuite 


Find Hootsuite online: 



We are hiring in a big way! Apply now 


Sent from my iPhone. 
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EXHIBIT 86 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 


Konstantinos Papamiltiadis 


Sent: Monday, March 30, 2015 6:04 PM 

To: 

Subject: Re: API's currently in use 

Attachments: image001.jpg; image002.jpg; image003.png; image004.jpg 


Hello 

Glad it all makes sense for you now, . I have now approval to get you an extension until the end of June 
for those permissions listed below in black. 

Even before we reach the deadline, we need to update the apps so that by the end of June an update has 
already reached the current user base. 

I will be working on the legal docs and send them your way soon, 
kp 


From: g)Airbiquity.com > 

Date: Monday, March 30, 2015 at 4:19 PM 
To: Konstantinos Papamiltiadis 
Subject: RE: API’s currently in use 

Hi KP, 

Yes, I'm aware that all of the "friends" APIs are going away and we've already removed those from our 
app. We are waiting for Nissan to decide what direction they want to go in when the only feature we can 
support is Events. 

I watched most of the f8 video presentations and I see now why Messages is being restricted. I also 
understand why the automotive experience is not as interesting to Facebook given the huge numbers of 
users you already have. 

Thanks for letting me know and I will get in touch once we know what our OEM client plans. 


From: Konstantinos Papamiltiadis 
Sent: Monday, March 30, 2015 4:03 PM 

To: 

Subject: Re: API's currently in use 
Hello 

Just fyi, there are certain things that are going away on 04.30, that we can't provide an extension for, namely: 
friends events 


l 


CONFIDENTIAL 


FB-0004285 6 



friends_activities 

friendsphotos 

I can try to get you an extension for the rest, but for the 3 ones above it won't be at all possible to support 
beyond 04.30. 

kp 


From: . g>Ai r biq uity.c om> 

Date: Tuesday, March 24, 2015 at 2:19 PM 
To: Konstantinos Papamiltiadis 
Subject: API's currently in use 

KP, 

I appreciate you taking the time to meet with and yesterday. 1 know that they were 

hoping to understand the reasoning behind the features being removed from our app. Hopefully, 
you were able to answer their questions so they can move forward 

asked me to send you the vl .0 API’s that we use and are trying to map to v2.x API’s. Here 
is the list but I’m assuming that all but user_events are either restricted or are limited by the 
permission process. 

offlineaccess 

readstream 

userevents 

readmailbox 

friendsevents 

useractivities 

friendsactivities 

userphotos 

friends_photos 

useractions; instapp 

publishactions 


Thanks, 


Airbiquity 
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EXHIBIT 87 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 




Tech Lead - Enterprise 



On Mon, Mar 30, 2015 at 12:00 PM, Konstantinos Papamiltiadis wrote: 

Hello 

And just to clarify, the dev/test accounts are for the same App ID that you use for your own real accounts or are you using 
them against a different app (most probably your test App)? 
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thanks a lot, 
konstantinos 


From: (S)lyft.com > 

Date: Monday, March 30, 2015 at 10:27 AM 
To: Konstantinos Papamiltiadis 

Cc: Francesca de Quesada Covey , (5)lvft.com >. Jon Park 

®lyft.com >. S)lvft.com > 

Subject: Re: Special API access 

Hey Konstantinos, 

We actually have lots of dev/test accounts. The ask is that right now they don't seem to be compatible with the whitelisted 
mutual friends API. They return a strange "Unsupported get request" when used with the mutual friends API while real FB accounts 
come back fine. It's made us unable to test this particular feature with our test accounts and instead been forced to do our QA with real FB 
accounts. 


Thanks! 


Tech Lead - Enterprise 


On Fri, Mar 27, 2015 at 5:51 PM, Konstantinos Papamiltiadis wrote: 

Hello 

I am trying to understand your set up and the ask below a little better before we can come up with a recommendation. 

Is the ask her for more dev/test accounts to be created under your production or development apps? 

Thanks a lot, 
kp 

From: 5>lvft.com > 

Date: Friday, March 27, 2015 at 4:52 PM 
To: Francesca de Quesada Covey 
Cc: (5>lvft.com >, Jon Park 

;5)lvft.com >. 

Subject: Re: Special API access 
Hey all, 

We've had one other small request come up. 

Facebook's API currently provides some great functionality for creating development accounts. This has allowed us to do a 
significant amount of testing signup flows and various scenarios without having to create fraudulent users. However, when 
talking with our QA team we've had some issues using the current development accounts with the new mutual friends API 
which has made testing some of the flows rather difficult. We've been creating additional accounts in the Facebook 
production context which then of course gets hit because QA is going to behave a little strangely. 
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Is there some way to enable the API to also work with the development accounts to reduce friction with our QA team? We'd 
really love to leverage our existing development users since we have a really robust setup with our development accounts 
that we can't currently leverage with mutual friends. 


Tech Lead - Enterprise 


On Fri, Mar 20, 2015 at 11:41 AM, Francesca de Quesada Covey wrote: 

Wonderful! 

Sent from my iPhone 

On 20 Mar 2015, at 11:06, fSlvft.com > wrote: 

Hey guys, 

Thanks for checking into this. We’ve updated how we’re using the API and it's now working just fine! 
Appreciate the help. 


On March 20, 2015 at 7:28:27 AM, Francesca de Quesada Covey wrote: 

Hi 

I checked into this. No bug. :) 

You need to call the API from your server and supply and appsecre_proof param. 

From the docs I sent: 

"Securing Your Request 

If you want to call this API on behalf of two users who are not friends, then you must 
provide the app secret_proof parameter along with the user access token when making the 
request. This means the API cannot be called from client code (e.g. from the Javascript SDK 
or an iOS or Androp app) and must instead be called from your server. 

Let me know if you have any questions. 

Warmly, 

Cesi 


From: g l yf t .c o m> 

Date: Thursday, March 19, 2015 at 8:56 PM 

To: fS)|yft.com >, Konstantinos Papamiltiadis 

.Jon Park 

Cc: Francesca Covey f5)lyft.com >.. 
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5>lyft.com > 

Subject: Re: Special API access 
Hi Cesi, KP, Jon 

Just checking in on the question from 


Roct 


On Wed, Mar 18, 2015 at 3:03 PM, (5)lyft.com > wrote: 

Hey guys, 

Thanks for the follow up on grandfathering permissions. I wish it was an option, but 
doesn’t sound like there’s any flexibility there. 

On a more important note, I have an urgent problem we ran into: The API seems to only 
show mutual friends between User A and User B if both users are actually Facebook 
friends with each other. The point of the mutual friends feature is to reveal mutual friends 
to people who don’t already know each other, so I’m sure this must be a bug. 

Can you check this out as soon as possible? We’re starting regression testing on this 
today and then shipping it to the app store, so I want to make sure this feature works 
properly. I’m guessing there’s just some kind of bug in the API right now. 

As an example, when I use the Graph Explorer (see query) to see mutual friends with my 
fiancee (we’re Facebook friends, of course). I aet mutual friends returned in the API: 
https://www.evernote.com 


When I do the same query (see query) on a coworker who I am NOT Facebook friends 
with, there are no results returned, despite the fact that we share many friends in 
common: 


If you could check this out quickly and let me know, I'd really appreciate it. I have a less- 
pressing question I’ll start a separate thread about to keep things organized. 


On March 17, 2015 at 10:27:53 AM, Konstantinos Papamiltiadis 
wrote: 


Just a side note, the All Mutual Friends API will only work for those users 
that have not x-outed from user_friends permission during the Login flow. 
There is no specific permission you need to request on top of this from the 
users. 

I hope this helps, 
kp 

From: Francesca de Quesada Covey 
Date: Tuesday, March 17, 2015 at 10:22 AM 
To: gJlyft.com >, 

gJlyft.com > 
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Cc: Konstantinos Papamiltiadis 


, Jon Park 


Subject: Re: Special API access 
+ Jon 
Hi 

We are not grandfathering in anyone for permissions. Since people will 
need to login using the new version of the API they will ask for the you to 
share this info. We are seeing very low opt out rates and do think it will 
impact the use of the service. 

Let me know if you have any other questions. 

Best, 

Cesi 


From: (S>lyft.com > 

Date: Tuesday, March 17, 2015 at 5:18 PM 
To: g>lyft.com > 

Cc: Francesca Covev , Konstantinos Papamiltiadis 

Subject: Re: Special API access 
Hi Cesi 

Any followups here on the permissions? I've invited to lunch on Friday 
as well. 

On Mon, Mar 9, 2015 at 7:09 PM, g>lyft.com > wrote: 

Cesi & KP, 

Following up, I had a couple questions for you guys or your team. For 
context, I’m the PM on the Profiles & Mutual Friends feature and I’m 
working through the implementation details. Would love your help here. 

1) Full API access. It looks like we still don't have proper whitelisted 
permissions for the mutual friends API. Those of us who are admins of 
our Facebook app can use the API, but when we test it with someone 
who is just a regular user of our app, we get this message: 

"(#10) To use all_mutual_friends on behalf of people who are not 
admins, developers and testers of your app, your use of this endpoint 
must be reviewed and approved by Facebook. To submit this feature for 
review please read our documentation on reviewable features: 
https://developers.facebook.com/docs/apps/review ’’ 

2) Login. I wasn’t totally clear what you meant by "Everyone will be 
given the opportunity to opt out or give permissions through the new 
login. All users will be required to use the new login. There's no way to 
have current users opt in for the feature.” Could you explain this a bit 
more? I was confused by conflating login with the permissions. My 
understanding is that users, even those who already log in with 
Facebook, will need to grant an additional permission for Lyft to have 

5 


CONFIDENTIAL 


FB-00042 903 



access to mutual friends. Is that “new login” or are you referring to 
something else? 

3) Grandfathering permissions. Today, we’re getting the default 
Facebook permissions from all users, which includes the mutual friends 
feature. We’d like to roll out the Mutual Friends feature on the Lyft 
platform, with all existing users opted into it. Can we grandfather over our 
existing user base, so we don't have to re-ask all users for permissions 
they’ve already been granting? Not doing this would massively cut the 
likelihood of seeing whether your driver or fellow passenger has mutual 
friends, because both sides will have to opt in. 

4) Opt out. lis there a way for the mutual friends themselves to opt out of 
being shown as mutual friends in the Lyft app? I couldn’t find any such 
preference, but I figured I might just be missing it. Also, is there a way for 
users to revoke the mutual friends permission from the Lyft app if they 
decide they no longer want Lyft to have access to it, without revoking 
access to the entire app? 

Would love to sort this out so we can lock down our launch plan. If any 
questions are unclear please let me know! 


Th3nk«; nil 


Product Lead I Lvtt for Work 


On March 6, 2015 at 12:51:19 AM, Francesca de Quesada Covey 
wrote: 


Apologies for the delay I was traveling yesterday. As KP 
mentioned you should have access to the api now. Please 
let us know if you have any questions or run into any 
hiccups. The paperwork is all inclusive of what needs to be 
done. 

You don't need to worry about any contracts for the api. 
This is a product we are testing and will be rolling out 
slowly. 

This is not a focus for F8. Have you spoken with the events 
team on how to promote Lyft life for F8? If you want me to 
speak with them and find out more let me know. 

Everyone will be given the opportunity to opt out or give 
permissions through the new login. All users will be 
required to use the new login. There's no way to have 
current users opt in for the feature. 

Great on the meeting. What time works? The following 
week on Monday would also work for us. 
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Best, 


Cesi 

Sent from my iPhone 

fin 4 Mar 2015, at 22:29, 
g)|yft.com > wrote: 

Hi Cesi, 

A few followups: 

1. Just checking if the whitelisting is 

complete. We would like to request 
whitelist on the orod ( ) 

and dev ( i apps. 

2. Are there any contracts or other steps 
besides whitelisting to launch a feature 
using the APIs? 

3. Is this a focus for F8? We are planning 
to launch the friends feature in 3 weeks 
and can time it for F8. Any promotion 
opportunity would be great. We are 
providing the transportation at F8 and so 
it might be cool to have the attendees use 
Lyft Line while in SF and show them 
mutual friends! 

4. In addition to being whitelisted to test 
the API, we also realised that the Apr 
30th change that requires users to "opt in 
to" the mutual friends permission, will 
require us to go back to our entire 
userbase that signed up via FB, to opt in. 
This can be a sub-par experience if some 
users do and others don't. Is it possible 
to have the existing userbase stay opted 
in? 


5. Re. your email about Mar 20th 
meeting: 

Good idea! I can certainly set that up. 
Depending on the features we want to 
discuss, I can invite the responsible PMs. 
Which ones should we plan to discuss. On 
our priority list right now are: 

Mutual friends - ongoing 
Events integration - Pending your 
feedback 


7 


CONFIDENTIAL 


FB-00042 905 



Allow users to "share ride status" on 
messenger/timeline/whatsapp -1 think 
we have all the info for that 
Messenger - smart prediction for 
transportation if passenger is planning to 
travel. 

App Invites - to invite Friends - Waiting 
for the iOS fix that Brendan talked about. 

Please let me know. 

Best, 


On Tue, Mar B, 2015 at 10:50 AM, 
Konstantinos Papamiltiadis 

wrote: 

Sure, we will take care of this and let you 
know when done. 

kp 


From: 

@lyft.com > 

Date: Tuesday, March 3, 2015 at 6:48 
PM 

To: Konstantinos Papamiltiadis 

,Francesca 

de Quesada Covev • 

(5>lyft.com > 

Subject: Re: Special API access 

Lyft PM 

Hi KP, Cesi 

Our app ID is .Would love 

to get whitelisted at your earliest. 


Roct 


On Tue, Mar 3, 2015 at 1:21 AM, 
Konstantinos Papamiltiadis 

wrote: 

Thanks a lot, Ime. 
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Hello 


We have designed the All Mutual Friends 
API for use cases exactly like yours. We 
believe surfacing Mutual Friends will 
increase conversion and add to the 
feeling of "safety". 

Please find attached the spec for this API 
for your consideration. The API is 
currently only available to a handful of 
partners via a whitelist that we will of 
course be happy to add you to - we will 
need your App ID for that matter. 

Let us know if you have any questions, 
kp 

From: Ime Archibong 

Date: Tuesday, March 3, 2015 at 8:41 

AM 

To: 

@ lvft.com > 

Cc: John Lagerling 
Konstantinos Papamiltiadis 

Francesca 

de Quesada Covey • 

Subject: Re: Special API access 

Hi 

Yes, we're deep in MWC craziness. Hope 
all is well with you. 

We have a new beta API that should 
make this possible for you. Cesi and KP 
(cc'd) should be able to walk your team 
through the details & timing. 

Ime 

Sent from my iPhone 

On Mar 2, 2015, at 10:21 PM, 

(5>lvft.com > wrote: 


Hi Ime, John 

You are both probably 
busy at MWC and so 
sending this note to both 
of you. 
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I wanted to reach out to 
you to understand the 
possibility of this new 
feature we are working 
on. Confidentially, we 
wanted to show Lyft Line 
riders their Facebook 
mutual friends. 

Unfortunately, the 
current social graph APIs 
only allow us to surface 
FB friends who are also 
using Lyft. In our case, 
knowing mutual friends 
even if the mutual 
friends don’t use Lyft 
would be a great ice 
breaker between the 
riders. Your response on 
the possibility that we 
can work with you to get 
a special access API and 
timing of it would be 
super helpful. 

Best, 


Direclor. Business 
Develooment 


This transmission may 
contain information that 
is privileged, 
confidential, legally 
privileged, and/or 
exempt from disclosure 
under applicable law. If 
you are not the intended 
recipient, you are 
hereby notified that any 
disclosure, copying, 
distribution, or use of 
the information 
contained herein 
(including any reliance 
thereon) is STRICTLY 
PROHIBITED. If you 
received this 
transmission in error, 
please immediately 
contact the sender and 
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destroy the material in 
its entirety, whether in 
electronic or hard copy 
format. Thank you 
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EXHIBIT 88 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 

Konstantinos PaDamiltiadis 

Sent: 

Wednesday, April 01, 2015 1:20 PM 

To: 


Cc: 


Subject: 

Re: FB graph API 


2pm on Friday is good for me. If that's fine with you, will you send me an invite? 


From: g > m i c rosoft.com> 

Date: Wednesday, April 1, 2015 at 1:08 PM 
To: Konstantinos Papamiltiadis 

Cc: 5)microsoft.com >, 8>microsoft.com > 

Subject: RE: FB graph API 


Does 2pm today work? (sorry, I know that's short notice) 

From: Konstantinos Papamiltiadis 
Sent: 01 April 2015 11:21 

To: 

Cc: 

Subject: Re: FB graph API 

Sure, let's do this. Let me know what time works best for you. 
kp 

F ro m: jS>micros oft.com> 

Date: Wednesday, April 1, 2015 at 11:01 AM 
To: Konstantinos Papamiltiadis 

Cc: g Pm icrosoft.com> 

Subject: RE: FB graph API 

KP - do you have time today or Friday to have a short call to review where we are please? I have a spreadsheet I can walk 
you through on our current app status. I d like to invite along too as she looks after our PSA service, which a 

number of apps run through. 

From: Konstantinos Papamiltiadis 
Sent: 30 March 2015 15:14 

To: 

Subject: Re: FB graph API 
Got it! Thanks a lot. 
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From: 5>microsoft.com > 

Date: Monday, March 30, 2015 at 3:06 PM 
To: Konstantinos Papamiltiadis 
Subject: RE: FB graph API 

It is called *PSA - it is a service that a number of our other apps/services use including the Windows 8.x People 

Hub. Tomorrow AM I am speaking to the PSA team and the Windows 8.x People Hub team to understand the impact on 

them. 

* I don't have the acronym 

From: Konstantinos Papamiltiadis 
Sent: 30 March 2015 14:54 

To: 

Subject: Re: FB graph API 

Not a problem. Which app is this btw? 


From: g>microsoft.com > 

Date: Monday, March 30, 2015 at 2:42 PM 
To: Konstantinos Papamiltiadis 
Subject: RE: FB graph API 

Thanks for cc'ing me. I am speaking to this team tomorrow around some of the downstream implications here, 
Kind regards, 


From: Konstantinos Papamiltiadis 
Sent: 30 March 2015 12:05 

To: Dhiren Patel 

Cc: 

Subject: Re: FB graph API 
Hello 

This is correct. From 04.30 onwards, even if you call the endpoint to get back fb profile data for user's friend, the API will not 
return anything. 

kp 


From: @microsoft.com> 

Date: Monday, March 30, 2015 at 12:01 PM 


To: Konstantinos Papamiltiadis 

, (5>microsoft.com>, 

@microsoft.com>, Stephane Crozatier 

Dhiren Patel 

Cc: ®microsoft.com>. 

Subject: RE: FB graph API 

5)microsoft.com> 
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Thank you for your prompt response! 


For the permissions that are marked as deprecated below, does that mean we can no longer request for that data? E.g. 
birthday, work history, location, website for the users friends will no longer be available? 


friends_birthday 

Deprecated 

friendsjocation 

Deprecated 

friends_work_history 

Deprecated 

friends_website 

Deprecated 


From: Konstantinos Papamiltiadis 
Sent: Friday, March 27, 2015 6:08 PM 

To: Stephane Crozatier; Dhiren Patel 

Cc: 

Subject: Re: FB graph API 
as an fyi 


Hello 

Could you please give me some context here? What is your App ID and where those permissions are going to be used would 
be very helpful. The reason I am suggesting having more context is based on the fact that every App Developer that request 
extended permissions will need to go through Login review now and is important to know how those permissions are in use 
before you can submit for approval by our review team. Net you may have been requesting userjocation before, but if there 
is no product featured powered by this, then the permission will be rejected. With regards to the specifics: 

1/ The table below is correct in terms of mapping, but please note that read_stream permission is going to be deprecated and 
as such non FB branded Apps will not be given access to it. 

2/ Besides the format of the response changing the other significant change is that me/friends will only return app users (i.e. 
User that have authorised the app) 

3/ User_friends permission does not require Login review. However be aware that people can x-out from this. In this case the 
API will return no results. 

4/ User don't need to re-auth when an access token that has not expired acquired against vl is in us - however the API will 
behave as if this is a V2 access token. 

I hope this helps, 
kp 

From: 5)micrpsqft. com > 

Date: Friday, March 27, 2015 at 2:18 PM 

To: ©micrqsqft.cpm>, Stephane Crozatier . Dhiren Patel 

Cc: ®mjcrosoft.com>, Konstantinos Papamiltiadis 

Subject: RE: FB graph API 

Thanks folks for your responses. Here are a few more questions that we have: 

1. For the login review, the table below is the list of permissions that we came up with. The VI permissions are the 
ones that we have been using so far and the table translates them to the V2 permissions. 

i. We just want to confirm if that's the right mapping, 
ii. For the permissions highlighted in yellow: 
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Friends_xxx: Are there any other permissions that replace them? Do we need a different 
approval process for these permissions or is this completely going away? 

Offline_access: What is the purpose of this permission? We see it used in our product 
code however not sure of the exact purpose. 

2. With the change in permissions will the data that is returned change? Will we get different/more/less name- 
value pairs in the responses of the queries we send? If so, can you provide the details of these changes? 

3. Do we need to specify any permissions for the 

request https: //graph.facebook. com/y2.0/me/friends/{Liser id} ? what about user_friends 
permission, is this required?! don't see this permission in the login review list, how do we get it approved if its 
needed? 

4. You mentioned below that the legacy access tokens remain valid, however if we use these tokens which have 
the vl permissions in the post April 30th API's, what's the expected behavior? Will there be an error or a re- 
auth? Will the return values be different? 


Thanks, 


VI permissions 

V2 permissions 

offline access 

?? 

read_stream 

read_stream 

user_birthday 

user_birthday 

userjocation 

userjocation 

user_website 

user_website 

user_work_history 

user_work_history 

friends birthday 

Deprecated 

friendsjocation 

Deprecated 

friends_work_history 

Deprecated 

friends website 

Deprecated 

publish_stream 

publish_actions 

userphotos 

user_photos 

friendsphotos 

Deprecated 

friends_videos 

Deprecated 

user_videos 

user_videos 


From: 

Sent: Thursday, March 19, 2015 5:33 PM 
To: Stephane Crozatier; Dhiren Patel 
Cc: Konstantinos Papamiltiadis 

Subject: RE: FB graph API 

Thank you for the prompt response - much appreciated! Will certainly come back with anything else once we've 
digested the answers. 


Thanlr won 
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From: Stephane Crozatier 

Sent: Thursday, March 19, 2015 5:29 PM 

To: Dhiren Patel 

Cc: Konstantinos Papamiltiadis 

Subject: Re: FB graph API 

+ KP fyi 

Hi 

Comments inline in red. 

Let us know if you have additional questions. 

Thanks! 

-stephane 

From: ®rnicrpsoft.corn> 

Date: Thursday, March 19, 2015 at 1:15 PM 

To: Dhiren Patel • , Stephane Crozatier 

Cc: ®mic r pspft.cpm>, @mi cro soft.com> 

Subject: RE: FB graph API 

+ Stephane, per OOF message. Thanks! 


From: 

Sent: Thursday, March 19, 2015 1:11 PM 

To: Dhiren Patel 

Cc: 

Subject: FB graph API 
Hi Dhiren, 

I'm 's manager and reaching out as she is currently on vacation. Our devs are working to implement upgrading graph 
API changes from 1.0 to 2.0, a change that we understand is taking effect at the end of next month. 

We've accumulated a fair amount of questions which I'll list below. However, if a phone call would make more sense to 
quickly go through these, we can certainly get that set up. 

Thanks a bunch for any help and insights! 


1. We would like confirmation that we will be able to simply change graph api by adding versioning with no 
additional changes to functionality or return type. 

a. http://graph.facebook.com/meto 

b. http://graph.facebook.eom/v2.0/me 

Yes, adding the version number will force the API to behave in the version specified. If the specified version is 
deprecated, the call will be defaulted to the next oldest version available. If you do not specify a version 
number, we'll also default the call to the next oldest version available. This means that calls to 
http ://g raph.facebook.com/me will automatically switch to v2.0 on April 30. We do recommend that you specify 
a version number, to better control which API version is being used and try to use the latest version whenever 
possible. 
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Moreinformationhere: htt p s :// developers.facebook.eom/doc s/ a pp s/versions#versioning 

For Fql.multiquery calls such as https://api.facebook.com/method/Fql.multiquery 
Do these need to be changed as part of the graph 1.0 deprecation? 

FQL does not change but will completely go away after we deprecate Graph API 2.0. We recommend that you 
use the "batch" Graph API for querying multiple requests: ht tp s://develo p ers.facebook.co m/ doc s/ g r a p h- 

What is the date when this type of api is no longer supported by FB? 

Same day as for API v2.0, which is available until Aug 7, 2016. 

If they need to be changed, is the correct mapping https://graph.facebook.eom/v2.0/fql? 

Continue to use https://api.facebook.com/method/fql.multiquery 

i. If this is the case the return data structures are different (XML vs graph). Can we get details 
about the response structure? 

There are fields we see in existing request and response that we have been unable to find any documentation about 
(for example) ispushable. 

Is there documentation on this? 

We do not provide general documentations on private APIs, but i'm happy to provide details on a case-by-case 
basis. "is_pushable" is a boolean value telling you whether or not the user is capable of receiving push 
notifications to any mobile device. 

What would be the FB behavior if we continue to pass this parameter, but FB no longer supports it? 

The behavior would be different depending on the type of query. If you try to fetch an invalid field, we would 
return an error code 100, with the message "(#100) Tried accessing nonexisting field (<fieldname>) on nude 
type (<nodetype>)". It's unlikely that we would deprecate a private API without letting you know in 
advance. We generally only allow specific developers to use private APIs and we monitor their usage. For 
example, we know that you are making 8.5M requests/day for this specific field on average. 

Additional fields requiring clarification 
Publish_stream 

This permission is no longer available, please use 'publish_actions' instead. 

Publish action 

Extended user permission required for publishing on their 

behalf: https://d evelopers.facebook.com/docs/facebook-login/permissions/v2.0#reference- 
publish actions 

Offline access 

This permission is usually automatically granted when using APIs that rely on it. You shouldn't be using it, 
but i may need to understand your specific use-case to provide a definitive answer. Can i ask which 
product this is for? 

Is there a testing server available which is already set up in the post 4/30/15 configuration so that we can confirm 
the validity of our changes? 

The online developers.facebook.com graph api explorer is insufficient for running testcases. 

We've been live since Apr 30, 2014. You can force API v2.0 calls by specifying the version number to the call (per 
your question above). 

You can also force test users into the post 4/30 configuration and test end-to-end scenarios: 

- Go to https://deyelopers.facebook.eom/apps/<your app id>/rqles/test r users/ 

- Click "Edit" on specific test user 
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- Select "Override the API version in Graph API requests for this test user" 

- Enable "Override" and select the API version you want to target 

I can also enroll specifc 'real' users into the post 4/30 configuration if you think that would simplify testing but 
would strongly recommend to use test users. 

Need clarification on changes required for authentication. Are there changes required for obtaining the access 
token? 

We currently use https://graph.facebook.com/oauth/access_token are there any changes beyond updating 
the url https://graph.facebook.eom/v2.0/oauth/access_token required? 

Any changes to parameters, permissions 

No change to access tokens, or authentication parameters. However, you may want to consider the 
following: 

- Login review. All apps must to go through "Login review" to be able to continue to use specific 
permissions post 4/30: https://developers.facebook.com/docs/apps/review/login . Because your case is 
special we will have to work together to get you approved (but you'll still have to submit your app). 

- App-scoped User IDs. People authenticating your app for the first time will be issued App-scoped User 
IDs with API v2.0. This means that IDs for the same user will be different between apps. 

Will the response structure change? 

No. 


Is there documentation of private Graph API, especially /me/importcontact. How does it work? What's the update in 
v2.2? 

This is to upload contacts to Facebook. I'll see if we have a doc for you, otherwise i can provide more information. Is 
this for Office365? 

This endpoint should not be affected by the Graph API vl.O deprecation in any way - you're sending us a 
list of contacts and we're returning the number of contacts processed. 

On May 1st, will the existing valid user token in user's mailbox become invalid since our app retrieved the token 
using vl.O API? Do users who use our app need to retrieve tokens again? What error code will the API return if 
there is any? 

Access tokens remain valid and are portable across API versions. 
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EXHIBIT 89 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 


Konstantinos Papamiltiadis 


Sent: Wednesday, April 01, 2015 5:28 PM 

To: Jon Park 

Subject: Re: API upgrade questions 

Attachments: image001.jpg; image002.jpg; image003.jpg; image004.jpg; image005.jpg; 

image006.jpg 


In the meantime, if they can create a unique URL for the object that would allow them to somehow uniquely identify the user. 
So here is the scenario 

Scenario: KP bought tickets for Jon, Patrick and Chris. 

Sender Flow: KP tags Jon, Patrick and Chris and they are now notified on Facebook when the activity is posted there. 

Receiver flow: Jon clicks on the URL and ends up back onTM. TM knows the name of friends tagged on this post based on the 
URL posted, and asks Jon if he is Jon/Chris or Patrick. Jon can then say, I am Jon, login or not and claim the seat. 

Makes sense? 


From: Jon Park 

Date: Wednesday, April 1, 2015 at 5:22 PM 
To: Konstantinos Papamiltiadis 
Subject: Re: API upgrade questions 

Oh this is amazing. Thank you! 


On Apr 1, 2015, at 5:18 PM, Konstantinos Papamiltiadis wrote: 

I talked to Eddie... So here is how I would have gone back to TM. 

Interesting use case, we would like to consider this use case in the near future, based most probably on 
Opaque IDs that would let you map a non-app friend back to a seat/event, etc without disclosing or sharing 
any non-app friend data. 

That said, we don't have the time to dig deep into this use case before the end of April and we would 
recommend that you factor the existing API restrictions into your migration efforts and then discuss about 
how we can support this use case once the migration is complete. 

Feel free to wordsmith this as you see relevant, but certainly let them know that they are not going to be 
whitelisted. 

Best, 

kp 


1 


CONFIDENTIAL 


FB-00042722 



From: Jon Park 

Date: Wednesday, April 1, 2015 at 3:24 PM 
To: Konstantinos Papamiltiadis 
Subject: FW: API upgrade questions 

Hey KP - 

Still talking to Ticketmaster about the seat mapping Ul:) 

Based on the examples the listed below, is there use case provide enough of a case to whitelist them? 


-JP 


F ro m: @LiveNatio n.com> 

Date: Wednesday, April 1, 2015 at 2:38 PM 

To: Jon Park STicketmaster.cpm> 

Subject: RE: API upgrade questions 

Hello Jon, 

Thank you very much for support. 

Here is the page with in t er active seat map, where each marker represents Facebook user by ID. 

Below you can see common use cases: 

1. When I'm going to attend the concert, I want to know, if my friends on Facebook are also going. 

On the interactive seat map there is a filter, that shows seats of all Facebook users or only the seats 
of my friends. 

Every seat on the map is associated with Facebook user id. 

After upgrade we'll be unable to see all friends, only app-scoped friends. 

2. When I want to tag my friend on the seat map, 

I chose a friend from the full list of friends, then put a marker on the seat. 

For this we need friend's id. 

3. When a Facebook user opens our website, if someone had tagged him on the seat (his id was found), 
then we ask him to confirm/remove tag. 

If you allow, I would like to ask your assistance with access_token API. 

I hope we will find the way to tag all friends. 

Thanks. 


From: Jon Park 

Sent: Wednesday, April 01, 2015 3:05 AM 

To: 

Subject: Re: API upgrade questions 
Hi 

Thanks for your email. Can you also provide more details on why you need to store user ID on the interactive 
seat map? Getting as much context here would help us understand this use case and determine next steps. 
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Thanks, 

Jon 


From: (SLiveNation.com > 

Date: Tuesday, March 31, 2015 at 12:50 PM 

To: Jon Park @T icketmaster.com > 

Subject: RE: API upgrade questions 

Hello Jon, 

On interactive seat map we store user ID, associated with a seat and we need only ID. 

Please take a look at response that we are getting from taggable_friends: 

It returns access_token, instead of ID. 

{ 

"id": "AaKJ-QN80IY3m- 

2DHeVnc5oQZFnx_VOptUF8XFEstr3EcSlLltvAxO_xptve3DWc_vllzPOs4RhVMOTklEqDvzCHMkEqFRMIku 

XtyXe5d901-Q", 

"name": "Somename someSurname" 

} 

Is it possible to get ID? 

{ 

"name": "Somename SomeSurname", 

"id"* ** 11 

} 

I suppose, we cannot get ID, because our test apps did not pass review of extended permissions 
"user_friends". 

Facebook app ID for example: 

Thank you very much for help! 


From: Jon Park 

Sent: Tuesday, March 31, 2015 12:50 AM 

To: 

Subject: Re: API upgrade questions 
Hi 

Can you elaborate on how Ticketmaster's tagging system is different from Facebook tagging, and why 
friends' FBIDs are required to be stored in your DB to enable this feature? While I understand that there 
may be some complexity, it would help us understand the challenges you may be facing with the current 
integration using the taggable friends API. 

However to reiterate, since the taggable friends API was created to prevent unnecessary exposure of 
user data, by principle we wouldn't expose friends FBID data via another endpoint and we should look 
into an alternative solution. 

Thanks, 

Jon 
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From: @LiveNation.com > 

Date: Monday, March 30, 2015 at 11:54 AM 

To: g)Ticketmaster.com >, Jon Park 

Subject: RE: API upgrade questions 

Hello and Jon, 

Thank you very much for help. 

This is a bit confusing, probably, but we have our custom system of "tagging", different from Facebook 
tagging. We "tag" friends on our interactive seat map. 

We store friends ID in our DB, and now we cannot store access_token because it cannot be compared 
with other userjds. 

Is there any other end point, that allows to get all friends ID, not only those, that have used this 
particular Facebook application? 

Thanks. 


From: 

Sent: Monday, March 30, 2015 9:42 PM 
To: Jon Park; 

Subject: RE: API upgrade questions 

who is the developer working on the API upgrade. 

, can you please explain why our current implementation needs access to non-app friend IDs and 
why access tokens won't work? 

From: Jon Park 

Sent: Monday, March 30, 2015 11:37 AM 
To: 

Subject: Re: API upgrade questions 
Hey 

I apologize for my delay in response. Currently in order to access non-app friends, we issue access tokes 
(per your dev's response), which is by design to protect our users' data. 

Can you provide more clarity on why your current implementation needs access to non-app friend ID's 
and why access tokens won't work? 

Thanks, 

Jon 


From: (S)Ticketmaster.com > 

Date: Thursday, March 26, 2015 at 11:18 AM 
To: Jon Park 

Subject: RE: API upgrade questions 
Hi Jon, 
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Our dev team is asking how to get friends' IDs that have not accepted this app? Right now, they can 
only get an access_token which doesn't work for us. Any ideas on how to resolve this? 

Here is the response from Dev in case this is helpful: 

We are still unable to get friends id, taggablefriends doesn't return id, it returns only 

access token, which we cannot store in our db. 

http://stackoyerflpw.coni/ 


From the information about taggable friends api 
http s: / /d e v elopers.fac ebo ok.com/ docs/apps/u pgrading: 

"New endpoints 

/me/taggable friends: The new Taggable Friends API. In the past if you wanted to tag friends in 
a post, you had to get their IDs, names and then pass that information into the post to tag them. 
With this new API you get a set of tokens that identify friends along with their names and 
pictures. Using this, it's easy to build a custom tagging interface from your app. If you use this 
feature, your app will have to go through review before it can tag people in posts or photos. 
Please note that the tokens returned through this API are not the same as the IDs returned via 
/me/friends." 

Also we found a petition https://www.chance.ore/ 

This is all that we have for now. 

Looking forward for an answer from facebook team. 

Thanks! 


From: Jon Park 

Sent: Tuesday, March 24, 2015 11:13 AM 
To: 

Subject: Re: API upgrade questions 
Hi 


1. Yes that's correct 

2. user_friends is a part of the basic permissions (what you've taken as a screenshot) - as long as users 
accept the basic permissions, they won't need to accept any additional perms. 


From: @Ticketmaster.com > 

Date: Tuesday, March 24, 2015 at 9:24 AM 
To: Jon Park 

Subject: RE: API upgrade questions 

Thanks, Jon. Couple of follow up questions to make sure I'm understanding correctly. 

1. If a user gives permissions to use user_friends, they would be able to tag friends that have not 
yet accepted the TM app permissions, correct? 
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2. Today we ask for access to friend list (see attached). Would current app users still need to 
accept the user_friends permission? 


Thanks! 

From: Jon Park 

Sent: Tuesday, March 24, 2015 9:10 AM 

To: 

Subject: Re: API upgrade questions 
[-Moving to BCC] 

Hi 

Thanks for your email. Please see my responses below: 

1) You could use the Taggable friends API for this use case, but the user will need to give permission to use 
user_friends. Our recommendation is for you to request this permission in context again if you want to 
enable this feature for people that have declined user_friends earlier. Since <5% of the users decline access 
to this permission, re-requesting user_friends permission shouldn't be a concern. 

2) I'm confirming that FB IDs acquired before their migration won't be updated to App Scoped IDs. 

Please let me know if you have any questions! 

Jon 

From: @Tic ketm a ster.co m> 

Date: Monday, March 23, 2015 at 11:31 AM 

To: Jon Park 

Cc: Jackie Chang 

Subject: API upgrade questions 

Hi Jon, 

We're in the process of upgrading all of our Ticketmaster apps to Graph API v2.2 and our dev team came 
across some possible limitations. Here are the questions they have asked me to reach out about. 

1. We are trying to retrieve friends IDs who have not accepted user_friends permissions. The 
reason we need to do this is because we have functionality that allows users to tag FB friends in 
seats once they have purchased tickets. Limiting to only friends who have accepted the app is 
not a good user experience for the ticket purchaser. Is there a way to get all friends via 
taggable_friends or any other endpoint? 

2. We store userjd in our database. Can you confirm that a user id that has logged in with this 
app before we upgraded to v2.2 will not change to the app_scoped_user_id and we won't lose 
our information? 

I'm also attaching screenshots of our tagging flow so that you can better understand what I'm asking in 

# 1 . 

Once I have purchased tickets and land on our purchase confirmation page, I am prompted to RSVP to 
the event: 
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After clicking Attending, I can tag any of my Facebook friends (regardless of whether they have accepted 
the Ticketmaster App permissions): 
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EXHIBIT 90 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 

Sent: 

To: 

Subject: 


@godaddy.com> 

Wednesday, April 15, 2015 12:31 PM 
Konstantinos Papamiltiadis 
Re: Connecting 


Hi KP, 

Apologies for the delay. Attached is the sample file. 
Thanks, 


Sr. Director, Corporate & Business Development 

GoDaddv 


From: Konstantinos Papamiltiadis 
Date: Tuesday, April 14, 2015 10:22 AM 
To: @godaddy.com > 

Subject: Re: Connecting 

Hello 

Any updates on this one? 

Thanks a lot, 
kp 


From: (5>godaddv.com > 

Date: Thursday, April 2, 2015 at 11:26 AM 
To: Konstantinos Papamiltiadis 
Subject: Re: Connecting 

Hey KP, 

I'll ask the team for a sample. Stay tuned... 
Cheers, 


From: Konstantinos Papamiltiadis 
Date: Thursday, April 2, 2015 8:03 AM 
To: @godaddy.com > 

Subject: Re: Connecting 

Hello 
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The team got back to me to suggest that your coverage is really good and if possible, we would like to get a sample of your 
raw data for restaurants in SF. 

Could you please help us get access to this sample? 

Thanks a lot, 
kp 

From: ggodaddy.com > 

Date: Wednesday, April 1, 2015 at 9:02 PM 
To: Konstantinos Papamiltiadis 
Subject: Re: Connecting 

Hey KP, 

Apologies, try this one. 

Thanks! 


Sr. Director, Corporate & Business Development 

GoDaddv 


From: Konstantinos Papamiltiadis 
Date: Wednesday, April 1, 2015 9:00 PM 
T o : S>godaddy.com > 

Subject: Re: Connecting 

Hello 

I can't see the attachment. Do you mind sharing again? 

Thanks a lot and congrats on the IPO!! 
kp 

On Apr 1, 2015, at 8:51 PM, I ggodaddv.com > wrote: 

Hi KP, 

Please find attached the filled out excel sheet. It contains restaurant data for 3 cities, San Francisco, New York 
and London, with venues categorized by publishable venues, open table venues and valid venues. 

Let us know any questions. 

Thanks, 


Sr. Director, Corporate & Business Development 

GoDaddv 
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From: Konstantinos Papamiltiadis 
Date: Tuesday, March 31, 2015 1:26 PM 
To: 5>godaddv.com > 

Subject: Re: Connecting 

Yes, of course congrats!!! 

Besides the spreadsheet, our eng team would love to have a sample of your raw data. Happy to swing bye 
and say hi when you are here on Friday. 

Thanks again and good luck, 
kp 


From: @godaddy.com > 

Date: Tuesday, March 31, 2015 at 1:20 PM 
To: Konstantinos Papamiltiadis 
Subject: Re: Connecting 

Hey KP, 

As you may have seen in the press, there has been a lot going on here so, apologies for the delay. 

I do have an engineer working on the spreadsheet you supplied and should have it to you by end of 
week. Also, I'll be down at FB HQ on Friday meeting with Neil and team. 

Thanks, 


Sr. Director, Corporate & Business Development 

GoDaddv 


From: Konstantinos Papamiltiadis 
Date: Tuesday, March 31, 2015 1:15 PM 
To: (5>godaddv.com > 

Subject: Re: Connecting 

Hello 

While I am trying to establish how a partnership involving 's team may evolve, is there any chance you 
can provide us with a sample of your data? 

As per our call it would be great to establish your content is indeed as suitable for our needs as we think it is, 
prior to going deeper into a conversation involving other teams/functions. 

Maybe all restaurants with their menus from SF would be a good starting point. 

Thoughts? 

kp 
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From: 5)godaddy.com > 

Date: Monday, March 16, 2015 at 8:19 PM 
To: Konstantinos Papamiltiadis 
Subject: Re: Connecting 

Hey KP, 

His name is . No worries. 

Cheers, 


(Blame any spelling errors on Siri - Sent from my iPhone.) 


On Mar 16, 2015, at 6:25 PM, Konstantinos Papamiltiadis wrote: 

Hello 

Could you please remind me of the name of the person you are talking to on the product 
side for the Pages Creation API access? 

Thanks a lot, 
kp 

From: [£>godaddv.com > 

Date: Monday, March 9, 2015 at 11:23 AM 
To: Konstantinos Papamiltiadis 
Subject: Re: Connecting 

Sure, 2:30 works. Can you send over an invite with the best number to reach you on? 
Thanks, 


Sr. Director, Business Development 

GoDaddy 


From: Konstantinos Papamiltiadis 
Date: Monday, March 9, 2015 11:19 AM 
To: 5>godaddy.com > 

Subject: Re: Connecting 

Hello 

Unfortunately, none of the below works for me. How about 2:30pm? 
Best, 

konstantinos 
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From: g)godaddv.com > 

Date: Monday, March 9, 2015 at 5:29 PM 
To: Konstantinos Papamiltiadis 
Subject: Re: Connecting 

Hi Konstantinos, 

No worries - Welcome to California! 

Wednesday looks good for me. How does 10am, 11am, or 2pm PST work for a call? 
Cheers, 


Sr Director, Business Development 

GoDaddy 


From: Konstantinos Papamiltiadis 
Date: Sunday, March 8, 2015 1:56 PM 
To: 5>godaddv.com > 

Subject: Re: Connecting 

Hello 

Apologies for the late response! I was moving to California from London last week and 
certain things, like responding to this, were lost... 

How is your schedule this week? Happy to make time around your availability. 

Let me know, 
kp 

From: 5>godaddy.com > 

Date: Tuesday, February 24, 2015 at 10:24 PM 
To: Konstantinos Papamiltiadis 
Subject: Re: Connecting 

Hi Konstantinos, 

Thanks for reaching out and providing additional information. 

Would be good to have a call around this before filling out all this information just to give an 
overview of how we view the Locu data today post acquisition by GoDaddy and in light of 
the new product we launched. Get Found . 

Here is some additional background -- 
> http://boss.blogs.nytimes.com, 


How does a call work on Friday at 10am PST? 
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Thanks 


Sr. Director, Business Development 

GoDaddv 


From: Konstantinos Papamiltiadis 
Date: Tuesday, February 24, 2015 9:01 AM 
T o : S)godaddy.com > 

Subject: Connecting 

Hello 

Moving our convo to our business email addresses. 

As a leading provider of information on services and places related to the food/restaurant 
industry, we would like to have a conversation with you about licensing your data. 
Restaurants, bars and night clubs are places where most people on Facebook check-in and is 
really important for us to ensure we have good coverage. 

Assuming this is of interest to you, we would like to confirm the coverage and the richness 
of your data for London, NYC and San Francisco. Could you please complete the attached 
spreadsheet for each of the named cities? In addition it would be very helpful, if you could 
also give us access to sample data (all restaurants in a neighborhood). 

Finally, we would like to understand the working model for licensing your data, so any 
information you can provide here would be very helpful. 

Looking forward to working with you, 
kp 
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EXHIBIT 91 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 


Konstantinos Papamiltiadis 


Sent: Wednesday, March 18, 2015 8:32 AM 

To: 

Cc: Francesca de Quesada Covey; Jon Park 

Subject: Re: Question for F8 


As promised, please find attached the docs for Hashed Friends API that can be used for social ranking. 

Let us know if this would be of interest for you, as we will need to sign an agreement that would allow you access to this API. 

In the meantime, let's please defer any convo on the API that could return signals about the authenticity of the account post 
f8. 

Any questions, let us know, 
kp 


From: @airbnb.com > 

Date: Tuesday, March 17, 2015 at 9:21 PM 
To: Konstantinos Papamiltiadis 

Cc: Francesca de Quesada Covey (S)airbnb.com >. 

(5>airbnb.com >, Jon Park 
Subject: Re: Question for F8 

Hi KP, 

Sure let's sync up at 8am PDT. What's a good phone number to call you? 

On Tue, Mar 17, 2015 at 9:14 PM, Konstantinos Papamiltiadis wrote: 

Hello , 

Can we synch up at 8am? I will be at a training from 9-6 both tomorrow and Thursday and Francesca is going to be on a plane. 

Thanks a lot, 
kp 

From: 5)airbnb.com > 

Date: Tuesday, March 17, 2015 at 10:39 AM 
To: Francesca de Quesada Covey 

Cc: Konstantinos Papamiltiadis , 5)airbnb.com >. 

@ a i rb n b.com>, Jon Park 

Subject: Re: Question for F8 

Hi Francesca, 

Would tomorrow (March 18th) at 10am PDT work for you? 
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On Tue, Mar 17, 2015 at 8:51 AM, Francesca de Quesada Covey 
Hi - 


wrote: 


Would it be possible to setup a call today or tomorrow to discuss the different options? 

Best, 

Cesi 

From: g>airbnb.com > 

Date: Tuesday, March 17, 2015 at 5:09 AM 
To: Konstantinos Papamiltiadis 

Cc: g>airbnb.com >. Francesca Covey 

(S)airbnb.com > 

Subject: Re: Question for F8 

Thanks KP, 

Just trying to understand this better from the technical side of things. 

If I understand correctly under the covers app scoped user ids can be still connected to actual FB user ids. App scoped user ids 
are there to prevent leaking user ids from one app to another. However, FB still can figure out what actual user id corresponds 
to an app scoped id (and figure out user profile creation date). 

Is my understanding wrong? Or is it technically infeasible or otherwise not considered as a option? If so why? 

On Mon, Mar 16, 2015 at 9:38 PM, Konstantinos Papamiltiadis wrote: 

Understood, that's why we are trying to work out a solution that would work for others and provide strong signal of 
authenticity. 

We will keep you posted, . There is appetite certainly to do something here, I hope after F8 we will have a few 
meaningful updates to share. 

Cheers, 

kp 


From: g)airbnb.com > 

Date: Monday, March 16, 2015 at 9:03 PM 
To: Konstantinos Papamiltiadis 

Cc: Francesca de Quesada Covey , t5>airbnb.com >. 

[S)airbnb.com > 

Subject: Re: Question for F8 

Hi Kp, 

Yes, that is correct. As our hosts invite guests to stay at their home, building trust is of utmost importance to us. A central 
piece in this context is our product "Verified Identity", where users verify a piece of their online and offline identity. 

A Facebook profile without a creation date is losing one of the best signals to evaluate the authenticity. While the number of 
friends is definitely one of the signals we evaluate, it's much easier to create for a fake account with a profile picture of a 
pretty girl or so. 
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Best regards, 


On Mon, Mar 16, 2015 at 8:32 PM, Konstantinos Papamiltiadis wrote: 

Hello 

I suspect you use the creation date as a signal for authenticity of the account; please correct me if I am wrong. 

We are aware this is a useful signal for a few of our partners and are working on getting a solution in place that will address 
this. 

However, until then, the only signal that you can use that comes from free is the number of friends a user has. The reason 
creation day can't be used as a signal any more is related to the fact we use app scoped ID that are not generated randomly 
and don't reflect the date the account was created. 

Best, 

kp 


From: Francesca de Quesada Covey 
Date: Monday, March 16, 2015 at 8:09 PM 
To: jSairbnb.com > 

Cc: @airbnb.com >. 5>airbnb.com >, Konstantinos 

Papamiltiadis 

Subject: Re: Question for F8 

+ KP to help answer any question ASAP today pacific time if needed; if not will look into this in am gmt. 

Thanks! 

Sent from my iPhone 

On 16 Mar 2015, at 20:23, g)airbnb.com > wrote: 

Hi Francesca, 

This is really unfortunate to hear, as it's probably the most successful signal right now to verify a Facebook 
profile. 

Also, the mutual friends API doesn't seem to be fulfilling our needs. Imagine we want to surface hosts in 
London, that you have a social connection with. We are obviously not able to query this API endpoint for 
every host in London with your access token individually. 

I would assume this is a common scenario for other companies as well. I remember, when I worked at Bing, 
we had the same scenario as well. How do other companies solve this? 

Best regards, 


On Mon, Mar 16, 2015 at 11:22 AM, Francesca de Quesada Covey wrote: 

Hi 

Hope you had a lovely weekend! 
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I've spoken with the team and unfortunately there's no way to request the creation date for a profile. The 
reason we are not allowing this is in order to protect our users. I understood from our conversation why and 
how you use it. I'm trying to figure out the best work around. Will get back to you ASAP> 

I've included the information on the mutual friends api below. This will be important to roll out as your 
currently ask for this permission and it will not work with the new version of login how you are doing it. I've 
gone ahead and proactively whitelisted your app. 

Please let me know if you have any questions. 

Best, 

Cesi 

1/ API 

Endpoint: graph.facebook.eom/ v 2.2/USER B ID?fie l ds=nam e , id,co n te xt.fields(al l mutual f ri endsl & access t 
oken=USER A TOKEN - where both user A and B must be app users 

Note that this API is available in v2.0, v2.1 and v2.2, but not vl.O. By default it returns a total count, and up to 
5 mutual friends. If you want more mutual friends, you can specify a limit param: 
...?fields=name,id,context.fields(all_mutual_friends.limit(200)) 

2/ Sample response: 

NOTE: we only return the ID field if the mutual friend is an app user. We return a token in all cases. The token 
will eventually be usable to redirect the user to the FB profile for that person l.e. 
www.facebook.com/ <TOKEN> but that's not done yet. 

{ 

"name": " ”, 

"id": "5943", 

"context": { 

"all_mutual_frierLds": { 

"data": [ 

{ 

"name": ” 

"token": 

"AS14nbpfmyXr44MjWyP8Gel_RmMiUjACrq0MH7581CzqG9DC25kophaa6jvUVZEYqpkFXU9kMMcTXY-nxc-N8acQ", 
"picture": { 

"data": { 

"is_silhouetto": false, 

"url": "https://fbedn-profiie-a.akamaihd.net/hprofiie-ak-xafl/v/tl.O- 
1/cO.5.50.50/p50x50/1928902_665659915031_7800315_n.jpg?oh=cf5d0386a572d44 0c75fc7da70b2dbda& 

oe=5539B823&_gda_=1428955376_232d7d0dd9758afadcbaa4936f949760" 

1 

1 

I, 


"id": "9074", 

"name": "Mike Vernal", 

"token": 

"ASnSiFqA0ZaebCx4Jok5bin237ez 6 6NvcFeqKe4Ze24m4PTNJITfcA9_2FHZ2uXoupOxMvAFTRpStcmeLugRjvhe", 
"picture": ( 

"data": { 

"is_sihouette” : false, 

"url": "https://fbedn-profile-a.akamaihd.net/hprofile-ak-xfpi/v/tl.0- 
l/p50x50/10245425_10101720899420561_471189U93667829994_n.jpg?oh=0659432782fe60c8ddb7ffle23 

685d8ds Oe=553 3 7 F5AS _gda_=1433214769_d0fecl2c36fd53d5986f83fbla344750" 

} 

} 


"id”: "11230", 

"name": " ”, 

4 


CONFIDENTIAL 


FB-00043833 




"token": "ASmfs9WPcAYUcSZkZYYI9d40vo5ZiNllA7- 
Ua z vxq5 5 Cpyc 971Sd zpLvKe 2 k kBqaAdRU_xMUtBtORMLITOMaT 9So", 

"picture": { 

"data": :{ 

"ir silhouette": false, 

"url": "https://fbcdn-profile-a.akamaihd.net/hprofile-ak-xaf1/v/tl.0- 
l/c8.0.50.50/p50x50/1959792_10101273193691431_1742964517_n.jpg?oh=bd9cdef942497b46d90d54d89 

8f865cd&oe=5537CE18&_gda_=1430135507_elee33a42ffb8c50f9f3191a7f4525bc" 

! 

} 

}, 

( 

"id": "11674", 

"name": ", 

"token": 

"ASn9NlX_vVUeUr09CT3OeUJSufq3S3_MlslGsdsaTZyPaCCtgeKBSDFerRtCKhlCZQBJfilXftAOE7smi5ddwVp6", 
"picture": [ 

"data”: { 

"is_silhouette”: false, 

"url”: "https://fbcdn-profile-a.akamaihd.net/hprofile-ak-xpal/v/tl.0- 
1/pS0x50/10603543_10101773261092351_8075915437065151803_n.jpg?oh=8d41771ebe86c501feb97e56a6 

73d58bSoe=556B842E&_gda_=1429703571_c79cc0934c3d703c44fe77b92e9427a6" 

} 

} 

l, 

( 

"id": "15150", 

"name": " ", 

"token": "ASnm0XryCoUFSd-0YxEXSZfQMw52Jxf_sJfu2ZIrqIDhTOQ2dv_bBhnS-U6ZuGkrsXdf- 
zstPONcMIgEWjvoL8ac", 

"picture": ( 

~ "data": { 

"is silhouette”: false, 

"url": "https://fbcdn-profile-a.akamaihd.net/hprofile-ak-xapl/v/t1.0- 
1/cll.11.141.141/s50x50/66942_762747565601_1090639_n.jpg?oh=ec23095d699beld55cf51Id9eall38c 

64oe=5533F271&_gda_=1433120160_2f43bc8695455e4f959921c96a02a6c0" 

} 

l 

\ 

1 , 

"paging": ( 

"cursors;": { 

"before": "MTAxMDE4NDkzNTI20TkxNiE=", 

"after": "MTUxNTA=" 

1 , 

"next": 

"https://graph.intern.facebook,com/v2.0/5943?pretty=0&fields=context.fields(all_mutual_frie 
nds.limit(5).after(MTUxNTA=))" 

i, 

"summary": { 

”total_count": 109 

} 

i 

} 

} 


From: g)airbnb.com > 

Date: Sunday, March 15, 2015 at 1:15 AM 
To: Francesca Covey 
Subject: Re: Question for F8 

Hi Francesca, 

Yeah, likewise. Looking forward to the API information. 
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Yeah, I definitely talk to your designers. I have best availability on Tuesday (either 17th or 24th). Let me know 
if that works. 

Best regards, 

On Sat, Mar 14, 2015 at 1:24 PM, Francesca de Quesada Covey wrote: 

Hi 

Great speaking with you yesterday. I'll send over the api info first thing Monday. 

Our designers love the AirBnB login flow. Would you be willing to talk to them before F8 to learn about your 
design? 

Warmly, 

Francesca 

Sent from my iPhone 
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EXHIBIT 92 

UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: @netflix.com> 

Sent: Wednesday, February 18, 2015 5:10 PM 

To: Chris Barbour 

Cc: Konstantinos Papamiltiadis; Dhiren Patel; ; Social Systems (GG) 

Subject: Re: Graph API 2.0 Migration 


No problem. See you tomorrow. 


On Wed, Feb 18, 2015 at 4:27 PM, Chris Barbour wrote: 

Sorry' about the delay, . Please come to building 18 tomorrow. 

Sent from my iPhone 

On Feb 17, 2015, at 3:58 PM, @netflix.com > wrote: 

Sure, sounds good. I’ll coordinate those on my side. What building should 
we show up at? 

Thanks, 


On Tue, Feb 17, 2015 at 10:38 AM, Chris Barbour wrote: 

Typically, I would offer to come to you all, but since I have a meeting kicking off at 10 at FB, it would be great 
if we could meet here. 

Chris 

From: S)netflix.com > 

Date: Tuesday, February 17, 2015 at 10:26 AM 

To: Facebook• 

Cc: Konstantinos Papamiltiadis 

5)netflix.com >. 

Subject: Re: Graph API 2.0 Migration 

Works for me ( may not be able to attend, but as this is technical, I don’t think 

it’s a big deal). Do you have a preference for Netflix vs. Facebook? 


Dhiren Patel 

5)netflix.com> 


On Tue, Feb 17, 2015 at 10:21 AM, Chris Barbour wrote: 

Flow about 9AM on Thursday, ? 
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From: g)netflix.com > 

Date: Tuesday, February 17, 2015 at 9:13 AM 
To: Facebook 

Cc: Konstantinos Papamiltiadis • Dhiren Patel 

S>netflix.com >. S)netflix.com > 

Subject: Re: Graph API 2.0 Migration 

Hey Chris, 

I think Wednesday or Thursday morning (anytime before 1pm) would work. We're 
flexible on location too. 

Regards, 


On Fri, Feb 13, 2015 at 12:33 PM, Chris Barbour • wrote: 

Thanks, guys. More than happy to meet and go through this stuff. Can you shoot over some availability for 
next week? I'm happy to come to you all or host you here. 

On Feb 13, 2015, at 12:30 PM, (5>netflix.com > wrote: 

Hi All, 

We’ve spent some more time working through our upgrade path, and 
have a bunch more questions. It might make sense to actually meet on 
this, but here are the questions: 

1. Since we will be whitelisted for getting all friends, not just 
connected friends, when user A connects for the first time, who 
was previously seen in the friend list of a connected friend B, 
should we assume in a subsequent request for the friend list for 
user B, friend A's id will change from an old id to an app scoped 
id? 

2. We currently use the "installed" permission to determine which 
friends are connected. If we're whitelisted to get all friends, will 
this be a different API than the current friend API? If so, we can 
just make two calls, one to each API, and compare to determine 
which friends are connected and which aren't. If not, will we be 
able to get the installed flag, or do we need to look it up on our 
side? 

3. In order to support a variety of image sizes, driven by a plurality 
of device requirements, we construct profile image urls using 
user ids and image size parameters. We do this so that we don't 
have to store 10s of image urls per user, and so we don't have to 
update our DB when a new image size is needed. Will there be 
any issues with constructing these urls, some of which will be 
using global ids (for non connected friends or old users) and 
some of which will be using app scoped ids? 

4. We are currently whitelisted for certain graph API calls. Will the 
transition from global user ids to app scoped user ids affect these 
APIs or can we just assume that they will work? 
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1. Graph Get Permanent Access Token 
("oauth/access_token") - used by connect flow 

2. API Grant Permissions 

C’method/auth.grantExtendedPermission") - used by 
signup flows for devices that don't have a permissions 
dialog (TV Ills, etc.) 

3. API login ("method/auth.login") - used by connect and 
sign up flows. 

4. Graph post message ("<TO USER>/threads") - used for 
1-1 recommendations. 

5. Graph Ordered Friends ("me/orderedfriends") - used by 
connect/refresh flows. 

5. What is the impact of upgrade on realtime updates? Specifically, 
will we get live updates for "user_friends" permission? 

6. Do UI changes have to be coupled with backend? In particular, 
what happens if our website switches to using v2.0 SDK but 
backend has not, would connect still work? 

7. Is there any change to where an app token can be used instead 
of a user token? 

Thanks, 


On Sat, Jan 10, 2015 at 5:20 PM, Konstantinos Papamiltiadis 
wrote: 

+ Chris who is actually taking care of Netflix these days - also moving Bryan to bcc to save his 
inbox 

Great news that you are making progress on your migration. 

Let us know if there are any other questions you would like our help with. Let's ensure this is 
a smooth one. 

kp 

On 9 Jan 2015, at 16:57, 5)netflix.com > wrote: 

Thanks Dhiren - that makes sense, and makes life a lot 
easier for us :) 


On Fri, Jan 9, 2015 at 3:59 PM, Dhiren Patel wrote: 

Hi 

You are correct, but to clarify: The IDs will stay the same from the point of 
the initial "contact" with the API, and with all future versions. You don't 
have to migrate all at once, you can make 1.0 calls with a 2.x ID. Maybe it 
will be easier to demonstrate graphically with my poor Excel skills: 
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Connects/disconnects don't matter here, if you installed Netflix with 1.0, 
you'll get the 1.0 IDs even if the user goes to their FB app settings, deletes 
the app, and reinstalls/authenticates with 2.x. 

Hope I’m covering your main question here; if not, happy to discuss further. 
Cheers, 

Dhiren 


From: 

Date: Friday, January 9, 2015 at 12:15 PM 

To: Bryan Hurren, Konstantinos Papamiltiadis, Dhiren Patel 

Cc: 

Subject: Graph API 2.0 Migration 
Happy new year, FB folks, 

We've been looking at what we have to do, server side, to 
upgrade to Graph 2.0. We have various database tables that 
are either keyed off or contain FB user ids, so the biggest 
risk for us is if these ids can ever change, for a given user. 
From the docs, we found the following statement: 

"No matter what version they originally used to sign up for 
your app , the ID will remain the same for people who have 
already logged into your app. This change is backwards- 
compatible for anyone who has logged into your app at any 
point in the past." 

Does this mean that, regardless of a user's connect behavior 
(i.e sequence of connects/disconnects that may occur 
before, during, or after the Graph 2.0 migration), the first 
time Netflix sees a given id for a user, it is always valid to 
use this id when making calls to Graph 2.0 APIs (before, 
during, and after migration), and Netflix will always see this 
same id in friend lists of the user's friends (before, during, 
and after migration)? 

Thanks, 
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EXHIBIT 94 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 

Konstantinos Papamiltiadis 

Sent: 

Wednesday, February 11, 2015 5:08 AM 

To: 


Cc: 

Bryan Hurren; Steve Jarrett 

Subject: 

Re: Automotive contact 

Attachments: 

image001.jpg; image002.jpg 

Hello 



This permissions won't be available to anyone post 04.30, so inevitably all similar integrations will be subject to the same 
deprecations/restrictions. 

Thanks a lot, 
kp 

From: @Airbiquity,com> 

Date: Tuesday, February 10, 2015 at 10:11 PM 
To: Konstantinos Papamiltiadis 

Cc: Bryan Hurren , Steve Jarrett 

Subject: RE: Automotive contact 

Okay, I understand what you're saying, I'm just disappointed that we won't be able to support the app properly. 

Is it possible for you to assure us that no other in-car systems are exempt from this restriction? I want to make sure I 
have all of the facts when we explain this issue to our OEM. 


Thankc 


From: Konstantinos Papamiltiadis 

Sent: Tuesday, February 10, 2015 1:40 PM 

To:. 

Cc: Bryan Hurren; Steve Jarrett 
Subject: Re: Automotive contact 

Hello 

Trust me when I say this, but this is not the first tim, I have a similar conversation with a partner of an in-car integration.... We 
have considered all those points below, but ultimately we think the experience of the in-car integrations Vs what people can 
experience using the main FB app is sub-optimal. 

For that reason, we have decided to include in-car head units, in the list of platforms we won't be supporting with access to 
the newsfeeds any longer. Please note, people should noy use the FB apps while driving, this is a given, but at the same time, 
we want them to get the full experience when they are legally able to do so. 

Best, 
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kp 


From: gAi rbiquity.com > 

Date: Tuesday, February 10, 2015 at 8:56 PM 
To: Konstantinos Papamiltiadis 

Cc: Bryan Hurren •_ _ Steve Jarrett 

Subject: RE: Automotive contact 

KP, 

I'm sorry to be so insistent, but I don't agree with this reasoning. 

1/ FB apps provide a better user experience overall 

I would agree with this if we're only talking about the UX on the phone. Users, by law, aren't supposed to be using their 
phones while driving, so the UX while driving is zero. Our solution allows them to continue using FB safely while driving. 

2/ FB adds features on the mobile apps every month - the release cycle of in-car integrations is way slower than that 
Our solution utilizes the cloud, so we can update our Flead Unit Platform (HUP) software whenever necessary and do so 
frequently. We don't rely on HU manufacturers, or car makers, to update the software we need when changes need to 
be made whether these are new features or bug fixes. 

So, as you can see, we feel that we're providing a safe solution for Facebook users while driving. I would appreciate an 
opportunity to speak with you or the Automotive team so we can explain our reasoning. Please let me know if this is 
possible. 

Thanks, 


From: Konstantinos Papamiltiadis 
Sent: Tuesday, February 10, 2015 12:29 PM 

To: 

Cc: Bryan Hurren; Steve Jarrett 
Subject: Re: Automotive contact 

Hello 

I appreciate your feedback, but we have made a decision not to support rendering of newsfeed inside in-car head units and 
thus we won't be approving those integrations. A few reasons below: 

1/ FB apps provide a better user experience overall 

2/ FB adds features on the mobile apps every month - the release cycle of in-car integrations is way slower than that 

So all in all, read_stream will only be approved for FB branded apps for platforms we don't have the resources the build the 
native apps on our own (Windows, Blackberry, etc). 

Existing apps based on the vl of the API will also need to go through Login review and as such read_stream will not be 
approved, so we are actively working with partners to migrate them to different solutions. 

I hope this makes sense, 
kp 


From: @ Airbiquity.com > 

Date: Tuesday, February 10, 2015 at 7:38 PM 
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To: Konstantinos Papamiltiadis 

Cc: Bryan Hurren 

Subject: RE: Automotive contact 


Steve Jarrett 


KP, 

I'm confused about why read_stream wouldn't be approved. The purpose of our app is to reduce the use of the phone 
while driving to avoid driver distraction. If a user's Facebook feed is important to them, we think it would be better to 
display or use TTS to read the feed from the car's head unit rather than have them fumble with their phone while 
driving. As far as I know, there is no other way for them to access their Facebook account while in their car. Millions of 
Nissan drivers are doing this today with our app (based on vl.O APIs) and Facebook and we believe they will want to 
continue doing so. Without the News Feed, there doesn't seem much utility for our users and we will have to 
recommend to our OEM that this app would be seriously degraded. 

As for photos, we were considering asking the user to approve the Photos permission, but we've decided that our use of 
photos is in-coming rather than out-going. As long as our user's friends have included them in sharing their photos we 
would be able to display them in News Feed updates. This goes away if read_stream is not approved however. 

I'm really concerned that the new rules will prevent us from supporting Facebook for our OEM customers, it is a highly 
desirable application but not if we are limited to Messages and Events. 


From: Konstantinos Papamiltiadis 

Sent: Tuesday, February 10, 2015 11:24 AM 

To:. 

Cc: Bryan Hurren; Steve Jarrett 
Subject: Re: Automotive contact 

Hello 

As per my previous note, read_stream won't be approved for an app like yours. 

Read_mailbox could be because eventually we may allow in car-apps with voice dictation to let people to reply to messages, 
but until then you can request for read_mailbox if you want to render messages on the screen. 

No issue with user_events. 

Not sure about the photos that you mentioned on the previous email... Can you please clarify? 

When people go through Login and x-out from the requested permissions, the API will return an error. You can find more info 

here on howto handle missing permissions: 

https://developers.faceboo k.c om 

I would advice you to go ahead and submit for review, for everything listed below with the exception of 
read stream. With that in mind I would not submit screenshots where you render the newsfeed or interactions of 
people with their friends stories. 

1 hope this helps, 
kp 
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From: S? Airbiquity.com > 

Date: Tuesday, February 10, 2015 at 6:16 PM 
To: Konstantinos Papamiltiadis 

Cc: Bryan Hurren , Steve Jarrett 

Subject: RE: Automotive contact 

KP, 

We have not submitted our app for review yet as we want to make sure we are capturing the correct screens for the 
permissions we need. The purpose of our app is to allow the user to view, or listen to via TTS, the most important 
Facebook information to them without having to use their smartphone while driving. Focusing on driver safety, we use 
TTS to listen to the News Feed, preset comments, and disable the Head Unit keyboard when the vehicle is in motion. In 
one of you last emails you had mentioned that read_stream might be approved if we were using TTS rather than just 
visual text. We're not aware of any other Facebook in-car solutions, but our OEM customers feel this app is very 
important to their customers. 

The permissions we're asking users to approve are: 

read_stream - Lets driver listen to their News Feed updates 
read_mailbox - Lets driver listen to their Messages 
user_events - Presents upcoming Events 

The status that I included in my previous mail was regarding expected error scenarios when permissions were either On 
or Off. We think we may have misinterpreted the information on your developer site as our app is different from a 
typical smartphone app. 

I've included some screenshots that we're planning to include with our submittal. Please let me know if you have any 
questions about this or anything else. 

Thanks. 


From: Konstantinos Papamiltiadis 

Sent: Tuesday, February 10, 2015 2:37 AM 

To: 

Cc: Bryan Hurren; Steve Jarrett 
Subject: Re: Automotive contact 

Hello 

I am afraid I have hard time to follow what's going on here. 

Could you please: 

1/ List the permissions you are requesting from the users? 

2/ Confirm you have gone through Login review? 

From the below it seems that you are requesting read_stream and user_events... which is not what you have originally 
suggested a few emails back. 

Thanks a lot, 
kp 
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From: g) Airbiquity.com > 

Date: Tuesday, February 10, 2015 at 12:47 AM 
To: Konstantinos Papamiltiadis 

Cc: Bryan Hurren . Steve Jarrett« 

Subject: RE: Automotive contact 

Hi KP, 

It's taken some time but we believe we're close to submitting our app for review. We do have some questions and I'm 
hoping you can direct me to the right resource to get some answers. It may be that we're just misunderstanding how the 
permissions are to be used, but the following comes from one of our developers who is commenting on the behavior we 
see in our testing. Choreo is our cloud app that uses the smartphone as the conduit to the car's head-unit. 

Please let me know what you think, 

Thanks, 


Brief Summary of API Expectation 

• Our expectation is that when we request content which the user has turned off, we will get a 31509 
error code, and will then be able to show the user a popup. 

Actual Implementation 

• Messages 

o Works. We receive the error code, and we show the popup. 


• Events 


o Instead of receiving the error code, we receive an empty response. We can't use that as a 
determining factor for showing the popup, because the user may just have zero events. 

• News Feed 

o All feed data still shows up even when it is turned off. There is nothing in the response to 
indicate that the permission for this feature has been denied by the user. 


• Photos 


o All photos still show up even when they are turned off. There is nothing in the response to 
indicate that the permission for this feature has been denied by the user. 

Possible Solutions? 

• Choreo has filed tickets for these issues with Facebook. Currently they are saying, look at the ICD - it's 
implemented correctly. 

• We will just have to live with the following behaviour until we get a resolution from Facebook. 

o Events will show empty list 
o News feed will still show up 
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o Photos will still show up 


From: Konstantinos Papamiltiadis 

Sent: Wednesday, November 19, 2014 6:50 PM 

To: 

Cc: Bryan Hurren; Steve Jarrett 
Subject: Re: Automotive contact 

Hello 

Access to readjnailbox provided the users can reply via VR would be approved then. 

Let me know when you go ahead with your submission and I will make a note to the team that does the Login review. 

Please ensure when you are about to submit that you provide screenshots for every place where those permissions are in use. 
If you are also considering asking for publishing permissions, please provide screenshots of how stories shared through your 
app will show up on Facebook. 

Best, 

kp 


From: gAirbiquity.com > 

Date: Wednesday, November 19, 2014 at 10:44 AM 
To: Konstantinos Papamiltiadis 
Cc: Bryan Hurren . Steve Jarrett 

Subject: RE: Automotive contact 

KP, 

Yes, Voice Recognition is supported in most modern head-units today and our app supports VR for responding to texts, 
messages, email, etc. As I said, we follow strict driver distraction rules, which OEMs require, so we utilize TTS and VR 
whenever possible. It is possible that some HU's won't support VR or TTS, but those are on the lower-end. 

Thanks, 


From: Konstantinos Papamiltiadis 

Sent: Tuesday, November 18, 2014 7:23 PM 

To: 

Cc: Bryan Hurren; Steve Jarrett 
Subject: Re: Automotive contact 

Hello 

Will there be a way for people to reply to those message using voice dictation? If so, that may be interesting. Otherwise, this is 
probably not going to be approved as per my earlier feedback. 

Best, 

kp 
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From: g> Airbiquity.com > 

Date: Tuesday, November 18, 2014 at 3:39 PM 
To: Konstantinos Papamiltiadis 

Cc: Bryan Hurren , Steve Jarrett 

Subject: RE: Automotive contact 

KP, 

So, we won't be able to display a user's messages from others on the HU? We are trying to limit the functions to those 
that don't cause driver distraction, and on most HU's, messages user TTS technology. Our goal is to limit the need for the 
driver to access their phone while driving. I'm concerned that we may not have a very useful FB tool if we can only 
display News, Status, Events, and Check-ins. 

Here is an example of the Message and Message Details HU screens today. The user can tap the "right arrow'' button to 
start the TTS feature. 


We will plan on providing the screen-shots for the other permissions we need, but please let me know if you think we 
can make a case for Messages as well. 

Thanks. 


From: Konstantinos Papamiltiadis 

Sent: Tuesday, November 18, 2014 3:20 PM 

To: 

Cc: Bryan Hurren; Steve Jarrett 
Subject: Re: Automotive contact 

Hello 

With the exception of readmailbox which is going to be available for specific use cases, in-car integrations 
may not be one of them, you should be fine submitting screenshots for the rest of the permissions and have 
them approved. 

I hope this helps, 
kp 

On 18 Nov 2014, at 12:47, $Airbiquity.com> wrote: 

Hi KP, 
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Thanks for getting back to me. I will forward your responses on to our development team. As for 
permissions, in addition to public_profile, email and user_friends, we will ask for these: 

user_checkins 

readmailbox 

uuser_photos 

Our understanding of the user_friends permission is that it will only return those friends who use 
Facebook and our application. Since our app is used only by owners of late-model Nissan and Infiniti 
vehicles, we believe the user base will be too small to make this feature useful. We will drop the 
"Display Friends" and "Nearby Friends" features we currently have and will focus on the features above. 

Please let me know if you think sending screen-shots of these features will be sufficient when we ask to 
have our app reviewed. 

Thanks again for your help. 


From: Konstantinos Papamiltiadis 

Sent: Tuesday, November 18, 2014 12:22 PM 

To: 

Cc: Bryan Hurren; Steve Jarrett 
Subject: Re: Automotive contact 

Importance: High 

Hello 

A few answers inline....{kp} 

F ro m : S>Airbiquity. com > 

Date: Tuesday, November 18, 2014 at 11:34 AM 
To: Konstantinos Papamiltiadis 

Cc: Bryan Hurren , Steve Jarrett 

Subject: RE: Automotive contact 

Konstantinos, 

Please let me know if you can answer our developer's questions below. We are working on an upgrade 
for one of our major auto OEM customers and I want to make sure we hit our schedule. 

Thank you, 


| Product Manager | Airbiquity | 

<image001.jpg> <image002.jpg> <image003.png> <image004.jpg> 


From: Bryan Hurren 

Sent: Wednesday, November 12, 2014 11:48 AM 
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To: Steve Jarrett 

Cc: Konstantinos Papamiltiadis 
Subject: Re: Automotive contact 


Hi 

Good questions. +KP the lead platform partnerships person for the team - he'll answer these questions much 
better than I can. 

Bryan. 


bryan hurren | strategic partnerships | facebook 


From: S>Air biquitv.com> 

Date: Tuesday, November 11, 2014 at 9:43 AM 

To: Bryan Hurren , Steve Jarrett 

Subject: RE: Automotive contact 

Hi Bryan, 

Thank you for offering to help us find the right resource to answer our questions. 

1. Our Facebook app is deployed in vehicles world-wide in production today and we integrate with 
unversioned graph api of Facebook. We would like to upgrade our apps to V2.0 one country at a time. In 
that context, will Facebook pose any limitations on talking to multiple versions of graph API until all the 
users have upgraded to V2.0? 

{kp> Not really. It's up to you to change the end points at your own convenience, 
considering the restrictions/content available in the V2 of the API. 


2. Do access tokens obtained through unversioned API work with V2.0 of graph API? As unversioned api 
will be deprecated on Apr 30,2015, will the tokens that are valid beyond Apr 30,2015 work with V2.0 
after Apr 30,2015? 

{kp} I believe the answer is yes here, as access tokens are not API dependent. 

3. Is there any limitation on tokens, generated through a specific version, have to be used only with that 
version of graph api? 

{kp} Same as above, I don't think this is tied to a version of the API, but I can double check. 

4. We noticed new error codes were introduced in V2.0 of graph api and we didn't find any information 
online regarding the codes. Is there any documentation that provides this information? 

{kp} We are constantly updating our docs with the error codes, best to search develope r s . facebook.com 
with the specific error code you are getting. 

5. We understand that our application will need to be reviewed by Facebook due to the permissions we're 
asking of the end-user. As our application sends Facebook information to a vehicle's head-unit, testing 
our app without a head-unit is not possible. We can offer screen-shots of the head-unit display for each 
element which requires a permission if that’s acceptable. Otherwise, we will need to make other 
arrangements. 

{kp | Can we please confirm what kind of permissions you ask for 9 Provide screenshots would 
suffice for our review team, but please ensure those are all documented and screenshots are 
attached. If you can tell me which permissions you are asking for, I can give you an idea of 
which ones may or may not be approved 
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Please let me know if any of these are unclear and I will get a clarification. 
Thanks again for your help and we look forward to the response. 


From: Bryan Hurren 

Sent: Monday, November 10, 2014 2:20 PM 
To: ; Steve Jarrett 

Subject: Re: Automotive contact 

Hi good to meet you. Send through your questions, and I’ll find the right person to help 
Bryan 


bryan hurren | strategic partnerships | facebook | 

From: !5>Airbiquitv.com > 

Date: Monday, November 10, 2014 at 1:06 PM 

To: Steve Jarrett 

Cc: Bryan Hurren 

Subject: RE: Automotive contact 

Understood. My development team just wants to get some clarification on the new API's that weren't 
clear to them on the Developer's Site. I promise to keep it brief and to the point. 

Thanks, 


From: Steve Jarrett 

Sent: Monday, November 10, 2014 11:57 AM 

To: 

Cc: Bryan Hurren 

Subject: Re: Automotive contact 

Scott is a friend and has moved on to a new team. 

Don't know the other guys. 

Bryan's team is the right team, but slammed. Hopefully can point you in the right direction, but most of the 
support is online 

Thanks, 

Steve 

<image005.png> 

Steve Jarrett 
Mobile Partnerships 
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From: ff>Airbiaui t v.com > 

Date: Monday, November 10, 2014 at 11:43 AM 
To: Steve Jarrett ■ 

Cc: Bryan Hurren 

Subject: RE: Automotive contact 

Thanks Steve. Here are the names of some previous contacts we've had there. The first two bounced as 
no longer with the company and the second two did not respond. 

Annand Sharma 
Bill Stephenson 
Scott Hannan 
David Pio 

Thanks, 


From: Steve Jarrett 

Sent: Monday, November 10, 2014 11:40 AM 

To: 

Cc: Bryan Hurren 

Subject: Re: Automotive contact 

+Bryan Hurren in our Partnerships team 

Bryan, who is the right person to help vith the API questions below? 

In what geographies are the cars shipping? Will also intro you the right sales guys managing Automotive so at 
least they know what you are up to. 

Thanks, 

Steve 

<image005.png> 

Steve Jarrett 
Mobile Partnerships 


From: g)Airbiquity.com > 

Date: Monday, November 10, 2014 at 11:35 AM 

To: Steve Jarrett 

Subject: RE: Automotive contact 

Steve, 

Here is some marketing info about the company with a little more info. We currently support 
Nissan/lnfiniti, Fiat-Chrysler, Ford, and Renault among others. 
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Airbiquity is the global leader in connected car services and a pioneer in the development and engineering of 
automotive telematics technology, the foremost application of Machine-to-Machine (M2M). Airbiquity enables the 
vision of the connected car today with the industry’s most advanced cloud based vehicle services delivery platform: 
“Choreo™ " Working in partnership with Airbiquity, Automotive Manufacturers, Tier 1 Suppliers and Wireless Carriers 
are delivering customized connected car solutions meeting the management, safety and infotainment needs of their 
customers in 50+ countries and 30+ languages. Looking beyond automotive, Airbiquity is extending its innovative 
solutions to enable the next wave of M2M applications serving the Home Automation, Medical and Utility industries. 
Learn more about Airbiquity by viewing this videoor visiting www .air biquity.com . 

Thanks again for your help. 


| Product Manager | Airbiquity | 


From: 

Sent: Sunday, November 09, 2014 11:33 AM 

To: 

Subject: Automotive contact 
Steve, 

Thanks for getting back to me. Airbiquity supports about 5M cars right now, globally, for OEMs like 
Nissan, Chrysler, Renault, etc. We support FB now in our solution but we’re still using the vl.O APIs. 
We're going to migrate to v2.0/2.1/2.2 but we have some technical questions that we can't get sufficient 
answers to on the forums. Our previous contacts there are no longer with the company so it would be 
helpful to know who we can contact. I don't anticipate we would need much more than a few email 
exchanges to get the answers we need. 

I really appreciate your offer to help and I hope you are doing well. 

Cheers, 
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EXHIBIT 95 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 

Konstantinos Papamiltiadis 

Sent: 

Friday, February 06, 2015 8:54 AM 

To: 

Eddie O'Neil; Simon Cross; Monica Tsang 

Subject: 

Re: Facebook Integration 


I think it's fair to say: "those are just addendum and we need to original contracts where access to private APIs may be 
specified" 

From: Eddie O'Neil 

Date: Friday, February 6, 2015 at 4:52 PM 

To: Konstantinos Papamiltiadis ,Simon Cross- , Monica Tsang 

Subject: Re: Facebook Integration 

What would I ask for? 

Eddie 

From: Konstantinos Papamiltiadis 
Date: Friday, February 6, 2015 at 4:21 AM 

To: Eddie O’Neil Simon Cross , Monica Tsang 

Subject: Re: Facebook Integration 

Hello All, 

I hope I am not missing something here, but the attached addendums (only one is fully executed btw), do not specify access to 
any private APIs in particular. 

The latter may be specified in the original contract which we have not been able to locate on our end and I guess they have 
not either. 

@Eddie, any chance we can go back and ask again? 
kp 


From: Eddie O'Neil 

Date: Thursday, February 5, 2015 at 5:44 PM 

To: Konstantinos Papamiltiadis , Simon Cross Monica Tsang 

Subject: Re: Facebook Integration 

Contracts attached. There are two here - between FB <=> DNP [vendor] and FB <=> Walgreens [photo kiosks installed in 
store]. 

Eddie 
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From: Konstantinos Papamiltiadis 

Date: Wednesday, February 4, 2015 at 10:36 AM 

To: Simon Cross Eddie O’Neil , Monica Tsang 

Subject: Re: Facebook Integration 

Legal sent me all the contracts they have on file for Walgreens and there is nothing related to auth.login (mostly NDAs and a 
Payment contract). 

Is it possible to ask them to send us the contract they are referring to as I think our copy may have been misplaced? 

Thanks a lot, 
kp 

From: Simon Cross 

Date: Wednesday, February 4, 2015 at 5:05 PM 

To: Eddie O'Neil , Konstantinos Papamiltiadis .Monica Tsang 

Subject: Re: Facebook Integration 
Yeah, pulling the contract would be good. 

I'm cool with them keeping auth.login as they already have it - removing it would be a distraction at this stage. 

Can we see what perms they're using? Obvs they may be affected if they're using friends_photos. 

Lastly, we need to get them Login Reviewed ASAP. 

S 


From: Eddie O'Neil 

Date: Wednesday, February 4, 2015 at 7:18 AM 
To: Konstantinos Papamiltiadis, Monica Tsang 
Cc: Simon Cross 

Subject: Re: Facebook Integration 
Sounds great - let me know what you find. 

Eddie 

From: Konstantinos Papamiltiadis 

Date: Wednesday, February 4, 2015 at 7:17 AM 

To: Eddie O'Neil ■ , Monica Tsang • 

Cc: Simon Cross 

Subject: Re: Facebook Integration 
Hello Eddie, 

I would love to check if we have a contract in place indeed (no reason to doubt their claim though), but more interested in 
finding out what it covers exactly and for how long.... 

Let me talk to contracts first if that's ok. 
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Best, 

kp 


From: Eddie O'Neil 

Date: Wednesday, February 4, 2015 at 3:12 PM 

To: Konstantinos Papamiltiadis , Monica Tsang 

Cc: Simon Cross 

Subject: FW: Facebook Integration 

Hi all - see blow for a question from a developer about their use of auth.login. 

Their scenario is a Walgreens photo kiosk with FB Login. Sounds like they are covered by a contract. 

He's asking if anything will break with the migration - my sense is "no", but wanted to make sure before I respond. 

Thanks, 

Eddie 

From: g>dnp.imgcomm.com > 

Date: Wednesday, February 4, 2015 at 7:02 AM 
To: Eddie O'Neil 

Subject: RE: Facebook Integration 
Eddie, 

We are not using Oauth to authenticate with Facebook, we are using the following URL provided by 

We have a contract for our generic implementation and Walgreens has a contract with Facebook for their app id.. 

WAG ID: 

Generic ID: 

Best Regards, 


From: Eddie O'Neil 

Sent: Wednesday, February 4, 2015 10:01 AM 

To: 

Subject: Re: Facebook Integration 

Hi - thanks for your note. A few questions: 

1/ what specific API(s) are you calling? 

2/ do you have any contracts in place with Facebook? 
3/ what's your app ID? 

Thanks, 

Eddie 
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From: Sdnp.imgcomrn.com > 

Date: Wednesday, February 4, 2015 at 6:53 AM 
To: Eddie O'Neil ■ 

Subject: Facebook Integration 

Hello Eddie, 

I'm still trying to get an official answer if you have a few seconds to read my previous email. Thank you for your time. 

I hope you're doing well. I'm following up to see if I could get an answer regarding the private login API. Thank 
you for your time and help. 

I work for DNP developing a printing solution that has been deployed to one of the largest pharmacy chains in 
the US. In 20111 went to the Facebook Open Graph Technology Day in Austin, TX and met Aryeh Selekman. 
Aryeh helped us gain access to the private API for logging into facebook so customers can download and print 
their Facebook photos from our kiosk software. The private API made sense because these systems don't have 
keyboards attached and an open browser window is a security risk. I'm trying to understand the future of this 
API as FB moves forward with oauth 2.0 and the latest graph API. Does Facebook have plans to shut down this 
private login method? 

Best Regards, 


From: Mike Tedesco 

Sent: Friday, December 19, 2014 5:00 PM 
To: ; Eddie O'Neil 

Subject: Re: Facebook Integration 

Hi . Thanks for reaching out. I'm connecting you with Eddie O'Neil who drives our Platform/API work. 
Thanks and best of luck. 

Mike 


From: 

Date: Friday, December 19, 2014 at 8:38 AM 

To: Mike Tedesco 

Subject: Facebook Integration 

Mike, 

Thank you for taking the time to read my email. I work for DNP developing a printing solution that has been deployed to 
one of the largest pharmacy chains in the US. In 20111 went to the Facebook Open Graph Technology Day in Austin, TX 
and met Aryeh Selekman. Aryeh helped us gain access to the private API for logging into facebook so customers can 
download and print their Facebook photos from our kiosk software. The private API made sense because these systems 
don't have keyboards attached and an open browser window is a security risk. I'm trying to understand the future of this 
API as FB moves forward with oauth 2.0 and the latest graph API. If have any information or can put me in contact with 
the right person I would appreciate it. 

Flappy Holidays and Best Regards, 
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Software Engineer II 

DNP IMS America, Corp. - Photo Imaging Division 


Disclaimer 

This message is the property of DNP ImagingComm America Corporation, or its affiliates It may be legally privileged and/or confidential and is intended only for 
the use of the addressee(s). No addressee should forward, print, copy, or otherwise reproduce this message in any manner that would allow it to be viewed by any 
individual not originally listed as a recipient. If the reader of this message is not the intended recipient, you are hereby notified that any unauthonzed disclosure, 
dissemination, distribution, copying or the taking of any action in reliance on the information herein is strictly prohibited. If you have received this communication in 
error, please immediately notify the sender and delete this message. 

Thank you. 
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EXHIBIT 97 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 

@okcupid.com 

Sent: 

Friday, March 13, 2015 4:08 PM 

To: 

Konstantinos Papamiltiadis; 

Cc: 

Ime Archibong 

Subject: 

Re: Intro 


I am back at work 3/23, but I guess can make an exception if you have new info to share. 


-Original message- 

From: Konstantinos Papamiltiadis 
Date: Fri, Mar 13, 2015 6:05 PM 
To: ; 

Cc: Ime Archibong; 

Subject:Re: Intro 

When is the earliest we can talk? 

On 3/13/15,4:04 PM, @okcupid.com> wrote: 

>Fyi: I am on vacation next week... 

> 

> 

> 

> 

> -Original message- 

> 

>From: Konstantinos Papamiltiadis 
> 

>Date: Fri, Mar 13, 2015 5:14 PM 
> 

>To: 

> 

>Cc: Ime Archibong; 

> 

>Subject:Re: Intro 
> 

> 
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>+ Ime 
> 

>How about we have a call on Monday? I would like to have Ime join us as 
>well; he leads Global Partnerships here at Facebook and I have the 
>pleasure to work for him. 

> 

>Thanks a lot, 

>konstantinos 

> 

> 

>From: (Sokcupid.com 

>Date: Friday, March 13, 2015 at 2:29 PM 
>To: Konstantinos Papamiltiadis 

>Subject: RE: Intro 
> 

>We should talk. This isn't getting us very far. 

> 

> 

>From: Konstantinos Papamiltiadis 
>Sent: Friday, March 13, 2015 4:29 PM 
>To: 

>Subject: Re: Intro 
> 

>Hello 

> 

>We have been looking at creating some immediate benefit here, in the 
interest of unlocking the situation re Tinder being considered for the 
>Audience Network sooner. In other words, if we invested the resources 
>to add the app blocking capability for advertisers within a month as 
>opposed to H2, would that have sufficient value? 

> 

>Let me know, 

>kp 

> 

>From: @okcupid.com 

>Date: Thursday, March 12, 2015 at 11:18 AM 
>To: Konstantinos Papamiltiadis 

>Subject: RE: Intro 
> 

>Konstantinos - We do massive business together. There’s a long list of 
>ways to enhance that. 3 Unblocking Tinder’s monetization 2 possibilities 
>isn't really a productive approach. Flonestly, you guys are chasing US 
>to do that deal, not the other way around. We’re happy to go with 
>someone else if you consider that such a big give; that’s not the 
>impression I got from the people I’m negotiating with. 

> 

>Best, 

> 
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>From: Konstantinos Papamiltiadis 
>Sent: Thursday, March 12, 2015 1:16 PM 
>To: 

>Subject: Re: Intro 
> 

>1 accept that what we have to offer may not be compelling enough for 
>you, which is why I have asked for your help to understand what would 
>make our proposal compelling. 

> 

>Do you have any thoughts here? 

> 

>Thanks a lot, 

> 

>konstantinos 

> 

>From: @okcupid.com 

>Date: Thursday, March 12, 2015 at 11:11 AM 
>To: Konstantinos Papamiltiadis 

>Subject: RE: Intro 
> 

>Konstantinos - We are very confident in the validity of our trademark 
>and our success against any opposition. I’m not sure what you’re 
>trying to accomplish by continuing to reiterate that. 

> 

>So far you’ve offered an amount of money that is irrelevant to our 
companies. You’ve also offered no material non-financial consideration. 
> 

>Am I missing something? 

> 

>Best, 

> 

> 

>From: Konstantinos Papamiltiadis 
>Sent: Thursday, March 12, 2015 1:10 PM 
>To:! 

>Subject: Re: Intro 
> 

>1 am still not sure what would make the proposal compelling for you. 
>Can you help me out here? 

> 

>We have been working with and his team in true partnership spirit 
>all this time, delivering value that we think is far greater than this 
trademark, so I want to ensure we continue working together 
cooperatively and I would appreciate your transparency here. 

> 

>As a side note, it’s worth reminding you that the current deadline to 
>oppose Tinder’s pending trademark application is March 18. We'd 
>obviously prefer to reach a deal before that deadline. If we have to 
>file the opposition, we may still be able to come to a coexistence 
>arrangement, but we will no longer be interested in acquiring your 
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trademark application and any common law rights you may have in 

> 3 Moments. z 

> 

>From: @okcupid.corr 

>Date: Thursday, March 12, 2015 at 10:38 AM 
>To: Konstantinos Papamiltiadis 

>Subject: RE: Intro 
> 

>Konstantinos - Ok, these are very uncompelling, which I can only take 
>as a reflection that this matter isn't that important to you. Is that 
appropriate? 

> 

> 

> 

>From: Konstantinos Papamiltiadis 
>Sent: Thursday, March 12, 2015 12:33 PM 
>To: 

>Subject: Re: Intro 
> 

>ln the short term, Tinder can use our mobile SSP (to be launched in a 
>couple of weeks time) that would allow them aggregate ads from direct 
>sales as well as other buyers of inventory. In the mid term, we are 
committed to consider Tinder for the Audience Network (Q3 most 
>probably), pending the introduction of a feature for the advertisers 
>that would let them select which apps their ads can show up. I am not 
>sure if you can consider this proposal non-monetary, as it will 
>unblock Tinder's monetization possibilities, but I thought it would be 
>helpful to share with you. 

> 

>konstantinos 

> 

> 

>From: Sokcupid.com 

>Date: Thursday, March 12, 2015 at 9:40 AM 
>To: Konstantinos Papamiltiadis 

>Subject: RE: Intro 
> 

>Konstantinos - I've yet to see a proposal for any non-monetary 
compensation. 

> 

> 

>From: Konstantinos Papamiltiadis 
>Sent: Thursday, March 12, 2015 11:38 AM 
>To: 

>Subject: Re: Intro 
> 

>Hello 

> 
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>1 want to ensure there are no grey areas here! Let me know if we can 
>jump on a call to discuss this today. 

> 

>Thanks a lot, 

>konstantinos 

> 

> 

>From: Konstantinos Papamiltiadis 

>Date: Wednesday, March 11, 2015 at 5:34 PM 
>To:! okcupid.com 

>Subject: Re: Intro 
> 

>The new app is related to photo sharing. It’s meant to allow users to 
>share photos with small groups of close friends. A user can share all 
>the photos in raw form, before they can curate to share them in social 
>apps or with broader audiences. So in other words, pretty different 
>from Moments within Tinder and as such we don’t believe there will be 
>any confusion; however I am open to discuss the details with and 
Jonathan and figure our ways we can avoid any potential confusion 
>within the respective product. 

> 

>1 was not sure there was a question about compensation, apologies; in 
>my mind we have been working collaboratively with and the team in 
>good faith for the past 16 or so months! He is a member of a trusted 
>group of advisers for our platform (Developer Advisory Board) and based 
>on our commitment to provide a great and safe experience for the Tinder 
>users, we have developed two new APIs that effectively allow Tinder to 
>maintain parity of the product in the new API world. 

> 

>konstantinos 

> 

>From: Sokcupid.corr 

>Date: Wednesday, March 11, 2015 at 5:23 PM 
>To: Konstantinos Papamiltiadis 

>Subject: RE: Intro 
> 

>Konstantinos - Without divulging too much, is the product similar to 
>our MOMENTS product? Will it cause confusion? These are basic 
questions that I don't understand why you aren’t more candid in answering. 
> 

>Also, you didn’t respond to the other half of my email re: compensation? 

> 

> 

>From: Konstantinos Papamiltiadis 

>Sent: Wednesday, March 11, 2015 7:21 PM 

>To: 

>Subject: Re: Intro 
> 
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>Hello 

> 

>Fair question! In principle, we want to ensure that we can use the word 
> 3 Moments 2 to name a new product we have in the making without exposing 
>ourselves to any risks. In the US Tinder has filled an application for 
>it, so all we are asking for is to let us use the term (co-exist), for 
>the rest of world, we intend to file the application and let you use it 
>in return. 

> 

>1 hope this helps, 

>konstantinos 

> 

> 

>From: @okcupid.corTV 

>Date: Wednesday, March 11, 2015 at 5:13 PM 
>To: Konstantinos Papamiltiadis 

>Subject: RE: Intro 
> 

>Hi Konstantinos - 
> 

>l’m still looking to understand what you’re going to do with the mark, 
>which is obviously central to our ongoing use of the mark. 

> 

>Also, I’m not really interested in cash compensation; I’m interested in 
>a deepening of the good faith and trust in our relationship. 

> 

>Just don’t want you to get on a plane if we don’t even have the basics 
>covered. 

> 

>Thanks, 

> 

>From: Konstantinos Papamiltiadis 

>Sent: Wednesday, March 11, 2015 6:59 PM 

>To: 

>Subject: Re: Intro 
> 

>Hello: 

> 

>We have 2 options here that I think may have shared with you 
>already but here again for completeness: 

> 

>Model 1: Assignment and license back 
> 

> * Tinder assigns all rights and interest in the name and trademark 
>MOMENTS to Facebook, including to take all necessary steps to prosecute 
>US Trademark Ser. No. 86159457 to registration, and assign it to 
>Facebook thereafter. Tinder to identify, maintain, and assign any other 
>active trademark applications or registrations for MOMENTS. 

> * Facebook pays Tinder a reasonable compensation for this assignment. 

> * Facebook licenses back to Tinder the right to use the name MOMENTS 
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>in connection with a photo sharing feature of its Tinder mobile app for 
>a 

>50 year renewable term. 

> * Facebook will seek trademark protection for MOMENTS internationally 
>at its discretion, and Tinder’s license will extend to any territories 
>where Facebook secures rights. 

> * Facebook maintains the exclusive right to enforce the trademark 
>MOMENTS at its discretion, but will consider in good faith any 
infringing uses that Tinder brings to Facebook's attention. 

>Model 2: Coexistence 

> 

> * The parties agree to coexist, worldwide. Specifically, Tinder 
>agrees not to take any action against Facebook for use of the name 
>MOMENTS in connection with a photo sharing product. 

> * The parties agree to work together to avoid any likelihood of 
>confusion. 

> * Tinder may maintain its US Trademark Ser. No. 86159457 at its 
discretion, and may make any new filings in its discretion, but will 
>not assert such filings against Facebook. 

> * Facebook may seek trademark protection for MOMENTS at its 
discretion in jurisdictions where Tinder has no existing filings, but 
>will not assert such filings against Tinder. 

>My understanding is that you already reviewed Model 1 and you decided 
>to maintain ownership of the Trademark and not sell it to us which is fine. 
>Flowever, I am trying to establish if we can consider Option 2. In this 
>scenario, we can both use the term moments in our respective products, 
>you maintain the US trademark and you let us seek protection in other 
jurisdictions. 

> 

>1 am more than happy to jump on a call to discuss this further with you! 
>More importantly, I can fly to Chicago on Monday if that will help us 
>close the deal. I want to ensure we have a holistic conversation about 
>this relationship during which I can explain the steps we are taking to 
>ensure both ends are happy with this partnership. 

> 

>Thanks a lot, 

>konstantinos 

> 

>From: (S)okcupid.com 

date: Wednesday, March 11, 2015 at 3:27 PM 
>To: Konstantinos Papamiltiadis 

>Subject: RE: Intro 
> 

>Hi Konstantinos - 
> 

>We want to be accommodating and flexible, out of respect for the deep 
relationship our companies have. I'm not exactly sure what you're 
>asking us to do (give you a license to the mark, sell you the mark, 

>etc.), I need to understand what you plan to use the mark for, and what 
accommodations you plan to make back to us for continued use of the mark. 
> 
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>Thanks, 


> 

>From: Konstantinos Papamiltiadis 
>Sent: Tuesday, March 10, 2015 5:25 PM 
>To: 

>Subject: Re: Intro 
> 

>Thanks a lot, 

> 

, great to connect with you. Please let me know when it would be 
convenient for you to discuss how we can reach a mutually beneficial 
agreement re the trademark. 

> 

>Best, 

>kp 

> 

> 

> 

>From: 

>Date: Tuesday, March 10, 2015 at 2:33 PM 
>To: Konstantinos Papamiltiadis 

@okcupid.com 
>Subject: Intro 
> 

>KP, please meet , one of Tinder's board members. 

>1 think it's worth while for you both to connect directly to discuss 
>the Moments trademark. 

> 

> 

> Founder & CEO, Tinder 
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EXHIBIT 158 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 

Sam Lessin 

Sent: 

Sunday, January 20, 2013 8:27 AM 

To: 

Deborah Liu 

Cc: 

Mike Vernal; Douglas Purdy 

Subject: 

Re: Weekly Platform Monetization HPM 


The nekko growth is just freaking awesome. Completely exceeding my expectation re what is possible re ramping up 
paid products. 

I would be really curious to see the stacked bar of spend / how it is growing. Is the growth propelled by a few guys who 
are really putting weight behind it or a bunch of people coming on in the 10s of K per day? Also, what percent are using 
the SDK and tracking value all the way through? 

Really great stuff 

S 
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EXHIBIT 170 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 


Mike Vernal 


Sent: Sunday, October 07, 2012 9:05 PM 

To: Mike Vernal; Mark Zuckerberg; Chris Daniels; Dan Rose; Douglas Purdy 

Subject: Message summary [id.364074027012189] 


Mark Zuckerberg: 

>l've been thinking about platform business model a lot this weekend. 

> 

>One thing I've been thinking about a lot this is that we really should start a payments product for real-world goods and 
offer it at a much lower rate outside of canvas. Mobile apps need something like this for real-world purchases as well 
since iOS only does virtual goods. If we layer in a service like this with our login, then that's a pretty awesome combo 
and a good reason for people to use FB platform. 

> 

>1 also think that if we make it so devs can generate revenue for us in different ways, then it makes it more acceptable 
for us to charge them quite a bit more for using platform. The basic idea is that any other revenue you generate for us 
earns you a credit towards whatever fees you owe us for using platform. For most developers, this would probably cover 
the cost completely. So instead of actually ever paying us directly, they'd just use our payments or ads products. 

> 

>A basic model could be: 

> 

>- Login with Facebook is always free 
>- Pushing content to Facebook is always free 

>- Reading anything, including friends, costs a lot of money. Perhaps on the order of ~$0.10 / user each year. 

> 

>For the money that you owe, you can cover it in any of the following ways: 

> 

>- Buy ads from us in neko or another system 

>- Run our ads in your app or website (canvas apps already do this) 

>- Use our payments 

>- Sell your items in our Karma store 

> 

>Or if the revenue we get from those doesn't add up to more than the fees you owe us, then you just pay us the fee 
directly. 

> 

>The rate of $0.10 / user each year might even be too low. For example, at that rate Spotify would have to spend just 
$3m per year with us in ads to be even and Pinterest would be around there too. We might be able to get this number 
to be meaningfully higher, especially if we don't charge until a dev has a meaningful number of users, like 50k or 100k. 

> 

>l've been reading a lot of books on finance and banking recently, and even though the idea of an information bank is 
not identical to financial bank, the comparison suggests some interesting things. 

> 

>For example, banks charge you interest for as long as you have their money out. Rather than letting devs pay a one 
time fee to fetch data, we could effectively do this by mandating that devs must keep data fresh and update their data 
each month for anything they call. 

> 
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>Another idea is charging different developers different rates for things. The whole banking industry is based on 
charging people different rates. It may be that instead of having a flat fee for everyone, we should instead try set a norm 
were there's some range but the expectation is each developer gets some rate specific to them once they're at scale. 

> 

>Anyhow, those are just a few thoughts. We should haven't finalized our plan here yet so we should keep discussing 
this. 

> 

>ln the meantime, I'd love to spin up an effort to build a real-world payments product for devs outside of canvas. 
Douglas Purdy: 

>1. We are beginning to work on a payment product that will work for real-world goods/services. We can review where 
we are with you next week. 

> 

>2. We are currently executing on the paid developer program ($99 for app) that we are plan on rolling out in January. 
We are still working through the plan for API calls. I suggest that we spend some time tomorrow discussing what you 
outline here. 

Christopher Daniels: 

>1 like the idea of giving our best partners/customers discounts on other offerings we have. Two thoughts, however: 1) 
for the things that we choose to charge for and make a profitable business out of, we should have confidence in our 
pricing such that we don't have to give anything away for free because each provides equal or more value than we 
charge. Said differently, if our prices are set correctly, nobody will expect us to give anything away for free because 
what we charge provides enough value. I want to seek a profitable business model for platform on its own before we 
start to think about packages/bundling. 2) rather than crediting revenue dollar for dollar, we should trade value based 
on the margin we earn. For example, a dollar of gross revenue from karma is much less profitable than from our ads 
business, so we shouldn't trade them 1:1. 
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EXHIBIT 172 


UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 


Mark Tonkelowitz 


Sent: Wednesday, February 04, 2015 9:59 PM 

To: Joseph Barillari; Mike LeBeau; Mike Vernal; Yul Kwon; Jeremy Galen; Mark Tonkelowitz; 

Ran Makavy; Evan Ling; Avichal Garg 

Subject: Message summary [id.663395043771422] 


Michael LeBeau: 

>Hey guys, as you all know the growth team is planning on shipping a permissions update on Android at the end of this 
month. They are going to include the "read call log" permission, which will trigger the Android permissions dialog on 
update, requiring users to accept the update. They will then provide an in-app opt-in NUX for a feature that lets you 
continuously upload your SMS and call log history to Facebook to be used for improving things like PYMK, coefficient 
calculation, feed ranking, etc. 

> 

>This is a pretty high-risk thing to do from a PR perspective but it appears that the growth team will charge ahead and 
do it. 

> 

Separately, Gravity team had been intending to ship the Bluetooth permission on Android at the same time - in fact 
we'd already delayed to accommodate more permissions from the growth team, but we didn't realize it was going to be 
something this risky. We think the risk of PR fallout here is high, and there's some chance that Bluetooth will get pulled 
into the PR fallout. Screenshot of the scary Android permissions screen becomes a meme (as it has in the past), 
propagates around the web, it gets press attention, and enterprising journalists dig into what exactly the new update is 
requesting, then write stories about "Facebook uses new Android update to pry into your private life in ever more 
terrifying ways - reading your call logs, tracking you in businesses with beacons, etc". 

> 

>Gravity had a great initial reception. This is because we took painstaking steps to ensure that we had a clear story of 
user value for the hardware and spoke from a position of transparency but not over-emphasis about the potentially 
scary bits. But we're still in a precarious position of scaling without freaking people out. If a negative meme were to 
develop around Facebook Bluetooth beacons, businesses could become reticent to accept them from us, and it could 
stall the project and its strategy entirely. 

> 

>So we're still treading very carefully, and of course the growth team is also managing a PR risk of their own with their 
launch. 

> 

>Given this, and the fact we have lots to iterate on with iOS, and we can still do non-beacon place tips on Android any 
time, we’ve been thinking the safest course of action is to avoid shipping our permission at the same time as "read call 
log". 

> 

>Normally we'd have to wait until July for the chance to ship again, since we only ship Android permissions updates a 
couple times a year as they tank upgrade rates. So our options, aside from the "ship together and pray" option which 
feels too risky to me, are to wait until July to ship the Bluetooth permission on Android or ask for a special exception to 
ship our permissions update sooner. 

> 

>Shipping permissions updates on Android has the downside of tanking upgrade rates, so we try to do it infrequently. 
But there could be an argument to doing it sooner in this case, as a compromise to allow both teams to continue moving 
fast, without unnecessarily conflating two PR risks into one. 

> 

>Wanted to make everyone aware of these options and welcome any thoughts/feedback about this. 
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Ran Makavy: 

>1 think separating the introduction of the two permissions to different releases makes sense. If there is a case to have 
another release before July, that would be a good compromise. 

Avichal Garg: 

>Yeah we should work with Lindsay and Will to figure out if we can do an intermediate release before six months 
Avichal Garg: 

>And what the optimal timing for that would be 
Yul Kwon: 

>(y) 

Michael Vernal: 

>1 acknowledge but tend to be less concerned about this risk than you guys are. 

> 

>1 don't think there's a world where we delay the growth permission to give gravity air cover, so I think the real options 
are what you layout: 

>1. Ship now 

>2. Try to get an exception in "'April 
>3. Ship in July 

> 

>My honest recommendation would probably be to go out with this launch, but if the team collectively feels strong 
about holding it I would investigate (2). 

Yul Kwon: 

>Just as a heads up, I was in a separate meeting with Lindsey today, and I got the impression that Release Eng would be 
very opposed to an intermediate launch. We should definitely explore this, of course, but should expect strong 
reservations. 

Yul Kwon: 

>Also, the Growth team is now exploring a path where we only request Read Call Log permission, and hold off on 
requesting any other permissions for now. 

Yul Kwon: 

>Based on their initial testing, it seems that this would allow us to upgrade users without subjecting them to an Android 
permissions dialog at all. 

Yul Kwon: 

>lt would still be a breaking change, so users would have to click to upgrade, but no permissions dialog screen. They're 
trying to finish testing by tomorrow to see if the behavior holds true across different versions of Android. 

Michael Vernal: 

>(y) 

Yul Kwon: 

>Mike V. - The Growth team's meeting with Mark is scheduled for tomorrow at noon. Javi's admin accidentally left you 
off the invite, so I asked her to add you. She said she was checking with your admin to see if you could make it, but we 
haven't heard back. Will you be able to join? 

Michael Vernal: 
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>Eep; will be hard. Will check tomorrow. 


Yul Kwon: 

>Ok, thanks. This is annoying. The Growth team and Noami agreed that you were critical, but this apparently fell 
through the cracks when they set up the meeting. The same thing happened to Sheryl and Cox, neither of whom will be 
attending as a result. 
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EXHIBIT 180 

UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL 



From: 

Matt Scutari 

Sent: 

Friday, November 15, 2013 4:53 PM 

To: 

Nicky Jackson Colaco; Maritza Johnson; Erin Egan 

Cc: 

Rob Sherman 

Subject: 

Re: HPM 


Android Permissions. Matt has been working with the privacy PM, PMM, and Legal to understand privacy risks associated 
with several Android permissions that will go out in the next release, including permissions associated with reading call logs 
and SMS. Simultaneously, we're working to mitigate policy risks associated with a proposed help center FAQ designed to list 
and provide an example of each permission. 

Follow Redesign. Matt is working with the privacy PM, PMM, and Legal to finalize help center and user ed content for the 
Follow redesign, which is slated to roll out to 10% on 11/20. 

Only Me Stickiness. Matt is providing policy feedback on a Mark Z. request that Product explore the possibility of making the 
Only Me audience setting unsticky. The goal of this change would be to help users avoid inadvertently posting to the Only Me 
audience. We are encouraging Product to explore other alternatives, such as more aggressive user education or removing 
stickiness for all audience settings. 

Privacy Shortcuts Icon (Mobile). In response to user confusion regarding the new padlock button for privacy shortcuts added 
next to user names in Android (users think their account is being locked down). Product has proposed removing the shortcut 
icon entirely. Matt is working with PR, Legal, and others to assess the risks associated with removal and explore any potential 
alternatives, such as redesigning the button. 

Public Posting UFI Test. Matt is working with Product and others to finalize the details surrounding a planned test of the new 
UFI and filters for public comments, including the scope and location of the test. 

Survey Issues. Yul Kwon and Mike Nowak are interested in exploring the legal and policy implications of 
matching privacy survey results to user behavior to assess the extent to which user intent and user behavior 
are aligned. We have advised that we should be prepared to take some action to remedy user confusion 
revealed in the survey, ideally for the entire user population but at least for the user in our sample for which 
we have actual notice of confusion. Mike seems reluctant to commit to concrete action in either scenario in 
the short term, although he has expressed that he goal ultimately is to improve user comprehension. 


Hope everyone has a great weekend! 
Matt 


Matt Scutari 

Manager, Privacy and Public Policy | Facebook 
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From: Nicky Jackson Colaco 

Date: Friday, November 15, 2013 at 4:05 PM 

To: Maritza Johnson Erin Egan Matt Scutari 

Cc: Rob Sherman 
Subject: RE: HPM 

Instaaram Directed Sharing . Nicky provided an update this week during our Weekly Privacy Download on directed sharing 
- now called 'Instagram Directs', which will launch on 12/9. As you know, this product allows people to send picture 
messages to a few individuals (max of 15). Because messaging is riskier from a material safety perspective, the core 
team is working on the following: 

1) Ensuring that we are staffed from a UO perspective to support additional reports of directed shares, and are in a good 
place to escalate potentially sensitive reports to our e-crimes team; 

2) Using our backend tools to help identify anomalous and potentially predatory behavior (for instance, men sending 
Instagram Directs only to women our young boys); 

3) Creating extra education in-product, in Help Center, and via partners like the Safety Advisory Board to demonstrate a 
commitment to educating teens and others. While in the longer term, we plan to have 'flyouts' to educate those identified 
as teens, in the shorter term we are baking education into the NUXes when the product launches. 

We also plan to brief the Safety Advisory Board early next week (likely Tuesday). 


From: Maritza Johnson 

Sent: Friday, November 15, 2013 3:28 PM 

To: Erin Egan; Matt Scutari; Nicky Jackson Colaco 

Cc: Rob Sherman 

Subject: Re: HPM 

Hi Erin — I'll write up the details about my meeting with Alan this afternoon, and reply to Joel's prior email 
about the MIT policy center. 


Have a great weekend, everyone! 
- Maritza 


Research 

Maritza attended a member meeting for MIT CSAIL's Big Data initiative. Sameet Agarwal, Pinkesh Patel, and 
Ryan Mack also attended. Between the four of us, we had great coverage on any topic someone might want to 
talk about related to big data: infrastructure, data science, and privacy. 1 heard from more than one attendee that 
they were excited to see our strong presence at the event 

Most of the presenters were MIT faculty and students presenting projects from the past year. There was a strong 
focus on results: lots of interesting demos and experimental results. The keynote speaker was Deb Roy, MIT 
professor and chief media officer at Twitter. He gave an excellent talk on the power of social media to augment 
the TV watching experience. His keynote isn't available yet, but here's a similar talk he gave in March 2013. He 
focused on Twitter data but it applies to Facebook as well. It's worth watching for the visualizations alone. 
http://www.voutube.com/watch?v=GiAVKr3nvvE 
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I was most interested in the sessions on big data applications, and privacy and security 

( http:/ / bigdata.csail.mit.edu/ann u al2013) . The speakers in the applications session spoke about applying data to 
public health problems, identifying genetic diseases, and improving education using MOOC data. It's great to 
hear positive applications of data that motivate solving the privacy questions. Each of the speakers noted that 
their research has been impeded by unsolved privacy questions like how do you obtain informed consent, and 
how do you design a system with transparency in mind In the privacy session, Danny spoke about designing for 
trust when users might fear surveillance. He proposed that accountability must be embedded in the system 
design so that questions about data provenance, use, and transfer can easily be answered. Here's a neat demo on 
visualizing public Tweets, http://mapd.csail.mit.edu/ 


Maritza also attended the first meeting of the Big Data privacy working group. The group plans to approach the 
problem using specific case studies. The tentative plan is to focus on the MOOC data set first, and walk through 
the process of applying the available technical solutions and policy guidelines to define an arrangement that 
would allow the data to be shared with researchers. As a subtask of this work, the group will decide on a set of 
assertions that describe a successful data sharing program. 

Maritza met with Alan Davidson to discuss the proposed MIT policy initiative. 

Maritza, Rob, and Erin continued to iterate on a proposal for a research program centered on the privacy 
paradox. 

Maritza continued to work with Cam and Bob Kraut on a proposal for a data donation program with Wolfram 
Alpha. 

— Maritza 


From: Erin Egan 

Date: Friday, November 15, 2013 2:02 PM 

To: Matt Perault , Nicky Jackson Colaco , Maritza Johnson 

Cc: Rob Sherman 
Subject: FW: HPM 

Thanks Rob. Others? 

From: Rob Sherman 

Date: Friday, November 15, 2013 2:00 PM 
To: Erin Egan 
Subject: HPM 

Log In Anonymously. Rob continued work with the Open Graph team on Log In Anonymously (name subject to change), a 
product that will let people use their Facebook accounts (or, potentially, another Facebook-mediated account) to log into 
apps without the need to provide personal information or consent to sharing of data. 

App post suggestions. To address concerns about apps posting "implicit" user actions back to Facebook timelines, the Open 
Graph team is working on a feature that will, on an opt-in basis, enable apps to send "suggested posts" describing your 
activity to a "locker" within Facebook. If enabled, users will be able to see potential actions they could post to their timeline 
and then tap on a suggestion to open up a pre-filled composer. Rob is working with the team on technical implementation 
details to address privacy concerns. 
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Stable identifiers. The privacy team is working to evaluate Google's recent move to restrict use of device identifiers on 
Android and limit companies' ability to combine them with personal identifiers — a key use case for Facebook and Atlas — 
potentially without subjecting Google itself to the same restriction. We're working to develop options for policy initiatives 
that can support product and partnership initiatives to compete effectively and address Google's approach. 

Do Not Track. Rob attended a meeting of the Digital Advertising Alliance, which is aiming to finalize a Do Not Track standard 
as soon as December or January. We're pressing DAA to address Facebook-specific uses in its standard to ensure that we can 
continue to operate key aspects of our service under its proposed DNT approach. 

India Privacy Legislation. Erin, Ankhi, Sarah, Emily and Rob will submit a draft of comments to the Centre for Internet and 
Society this week. This is an Indian NGO that is preparing a so-called "consensus" draft of privacy legislation, which will 
precede introduction of privacy legislation sponsored by the Indian government. 

Brazil. The Internet Framework bill was amended to include some problematic new language on jurisdiction, personal data 
and penalties. Emily, Rob, and Katherine are developing proposed language to address issues with these new proposals. 

International Privacy Policy Tracking Chart. Emily is finalizing a tracking chart to be debuted at the next Weekly Privacy 
Download. The chart will help us monitor developments in privacy regulations globally, focusing on high priority jurisdictions 
and highlighting problematic issues and any deadlines for intervention. Ultimately the chart's content can be used to create 
one-pagers. 

Privacy group engagement. The privacy team worked this week with a number of privacy and trade groups, including the 
Future of Privacy Forum, Center for Democracy and Technology, the IAB and DMA. Of particular note this week, Emily is 
evaluating the possibility of joining the US Council on International Business (USCIB) and Maritza and Rob are working with 
the Direct Marketing Association to provide guidance on its new academic research initiative, which we are encouraging 
them to focus on the benefits of data to individuals and the economy and how we can better understand the "privacy 
paradox" - the disconnect between what people say about privacy and what they actually believe. 

Privacy Roundtable. Rob, Marcy, and Emily are working with the privacy PM and open graph teams on an event tentatively 
scheduled for MPK in January, where we'll bring in a group of privacy influencers to learn more about Facebook, our privacy 
and product design process, and to build relationships with privacy stakeholders within the company. 
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